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1.0  CRAMTD  STP  #22 
Results  and  Accomplishments 


1.1  InlEadu£l|on^and^£a£M£2MBd 

STP#22  started  May  1,  1994  based  on  technical  and  cost  proposals  dated  April  20,  1994  that 
were  submitted  to  the  DLA  on  April  22,  1994  and  ended  July  29,  1995.  Final  approval  for  the 
project  was  received  on  May  26, 1994.  The  broad  objective  of  the  project  was  to  develop  an 
Electronic  Data  Interchange  (EDI)  informational  model  that  could  serve  as  a  practical  tool  for 
engineering  and  system  design  and  for  management  decision  making. 

A  growing  form  of  interaction  between  organizational  information  systems  is  the  use  of 
paperless  information  through  EDI.  The  implementation  of  EDI  began  in  the  early  1980’s  and 
has  reached  a  point  where  large  and  medium-size  companies  demand  that  their  suppliers  use 
EDI.  Hence,  by  adopting  EDI  companies  will  have  a  competitive  advantage. 

For  an  EDI  system  to  be  effective,  the  trading  partners’s  internal  information  systems  must 
contain  three  fundamental  components:  a  communication  network,  translation  software  that 
converts  the  internal  data  format  to  the  message  standard  and  vice  versa,  and  the  application 
which  is  the  business  function  where  information  is  generated/needed,  e.g.,  purchasing,  material 
management,  quality  management.  It  is  important  to  ensure  the  proper  integration  of  an  EDI 
system  with  the  enterprise’s  application. 

Typically,  EDI  has  been  used  to  transmit  business  documents  such  as  bids,  invoices  and 
orders  between  a  customer  and  suppliers,  thus  avoiding  paperwork  and  repeated  data  entry. 

Conceptually,  the  scope  of  EDI  could  be  extended  beyond  transmitting  business  documents 
between  customers  and  suppliers.  Specifically,  it  should  be  possible  through  a  fully  integrated 
EDI/CIM  system  to  enable  a  customer  to  interact  with  their  suppliers  using  structured  messages, 
requesting  information  about  the  quality  assurance  test  results  of  the  products  at  the  supplier’s 
manufacturing  plant  in  a  timely  manner.  As  a  result  of  such  access,  the  customer  is  aware  of  the 
quality  aspects  of  the  product  before  it  is  shipped  from  the  supplier’s  plant.  The  customer  would 
be  assured  of  the  shipment  of  those  products  that  meet  his  quality  standards. 

With  the  capability  of  a  fully  integrated  EDI/CIM  system,  producers  now  limited  to 
Government  products  may  be  convinced  to  compete,  and.  thus  insuring  their  survival,  in  civilian 
markets  where  many  large  companies  are  urging  and  in  some  cases  demanding  that  suppliers  use 
EDI.  Further,  civilian  producers  who  already  use  EDI  could  be  shown  how  to  interface  with 
Government  EDI  systems,  hence  being  able  to  broaden  their  customer  base. 

The  product  of  this  Project  was  to  be  a  useful  and  accurate  model  of  the  flow  of  EDI  data  in 
an  interactive  production  environment,  which  is  an  essential  part  of  a  Computer  Integrated 
Manufacturing  (CIM)  system.  Such  a  model  would  be  invaluable  in  the  development,  testing 
and  evaluation  of  strategies  and  control  schemes  for  the  automated  handling  of  products  in  the 
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system.  Application  areas  span  a  wide  variety  of  industries,  from  those  using  traditional 
management  systems,  to  those  employing  the  more  exotic  high-tech  systems. 

1.2  Results  and  Conclusions 

Following  a  review  of  current  EDI  practices  and  the  availability  of  EDI  hardware  and 
software,  evaluation  techniques  and  criteria  were  defined  to  assist  selection  of  EDI  translation 
software  to  meet  the  particular  needs  of  a  potential  trading  partner. 

Trading  Partner  PC  version  4.40  software  from  TSI  International  was  purchased  and  installed 
at  the  CRAMTD  Demonstration  Site.  Key  business  transactions  requiring  the  support  of  the 
plant  Oracle  database  were  identified  and  scripts  written  to  integrate  these  EDI  transactions  with 
the  database. 

An  EDI  trading  partner  relationship  could  not  be  established  with  DPSC  Subsistence  during 
the  time  of  the  STP.  Since  the  software  remains  installed  at  the  Demonstration  Site,  such 
Interchange  should  be  established  at  such  time  as  both  “trading  partners”  are  technically  ready 
and  then  retained  as  a  demonstration  for  the  Combat  Ration  industry. 

A  ground-breaking  aspect  of  this  STP,  incorporation  of  product  quality  data  into  the  EDI 
transaction  set,  was  not  accomplished.  The  pilot  effort  at  the  National  Institute  of  Science  and 
Technology  (NIST)  which  was  to  include  product  description  in  future  EDI  transactions  did  not 
reach  the  stage  where  CRAMTD  EDI  participation  was  possible. 

1.3  Recommendations 

It  is  recommended  that  EDI  be  continued  as  an  aspect  of  the  Food  Manufacturing 
Technology  Facility  (Demonstration  Site)  and  that  opportunities  be  sought  with  DPSC,  NIST 
and  commercial  entities  to  establish  a  demonstration  EDI  trading  partner  relationship.  At  such 
time  as  active  Trading  Partner  relationships  are  closer  to  being  established  in  Operational 
Rations,  the  CAFT  Food  Manufacturing  Technology  Facility  (Demonstration  Site)  can  provide 
workshops.  In  concert  with  DPSC  Procurement  activities,  the  Demonstration  Site  under 
CORANET  DEMO  and  a  CORANET  Short  Term  Project  can  also  undertake  a  proactive  role  in 
supporting  Combat  Ration  Producers  becoming  Trading  Partners  to  DPSC. 

Transmittal  of  product  quality  data  is  included  in  the  objectives  of  the  “Vendor  Evaluation 
System”  (see  Final  Technical  Report  FTR  20.0,  “Vendor  Evaluation  System”,  STP  #60. 

Available  from  The  Center  for  Advanced  Food  Technology,  120  New  England  Avenue, 
Piscataway,  NJ  08854,  Phone  (908)  445-6130,  FAX  (908)  445-6145).  EDI  transactions 
consistent  with  ANSI  X.12  standards  may  be  the  best  format  for  commercial  applications. 
Accordingly,  EDI  technology  would  be  appropriate  to  include  in  the  final  DPSC  vendor  quality 
data  acquisition  system.  A  relationship  with  NIST  to  “standardize”  product  quality  data  should 
continue.  In  any  event,  establishing  a  capability  for  such  transfers  should  maximize 
compatibility  between  hardware  and  software  requirements. 
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2.0  Program  Management 


STP  #22  was  a  three-phase  work  activity.  The  three  phases  had  the  following  general 
objectives: 

Phase  I  Analyze  current  business  practices  and  review  existing  EDI  hardware, 

software  and  protocols,  selecting  that  suitable  for  the  proposed  EDI/CIM 
implementation. 

Phase  II  Acquire  necessary  hardware  and  software,  install  in  the  CRAMTD  site, 
define  required  modifications  to  effect  CIM  integration  and  develop  such 
modifications  as  are  consistent  with  the  time/resource  scope  of  the 
project. 

Phase  III  Demonstrate  the  functional  EDI/CIM  system  in  the  CRAMTD. 

A  limited  version  of  a  selected  EDI  system  is  to  be  installed  and  tested  from  the  perspective 
of  a  combat  ration  producer,  investigating  the  need  for  customization  of  the  selected  EDI  in  order 
to  merge  that  system  with  internal  systems  (CIM)  to  achieve  an  integrated  enterprise 
management  system.  An  evaluation  procedure  will  be  developed  to  assist  in  the  selection  of  EDI 
translation  software  by  combat  ration  producers.  The  work  activity  and  status  are  illustrated  on 
the  attached  Figure  1,  CRAMTD  STP#22  “EDI/CIM  Model  and  Demonstration”,  Time  and 
Event  Milestones  (Appendix  4.1). 

2.1  Summary  of  STP  Accomplishments 

•  Current  business  practices  determined  and  described  in  Technical  Working  Paper 
TWP  95  “Electronic  Data  Interchange:  Introduction,  Concepts  and  Examples”. 

•  CRAMTD  provided  a  manned  exhibit  at  the  DPSC-sponsored  EDI  Conference  and 
Trade  Show,  October  1994,  in  Philadelphia. 

•  Criteria  for  evaluating  EDI  translation  software  were  developed  and  reported  in 
Technical  Working  Paper  TWP  #98. 

•  Two  complete  EDI  software  packages  were  obtained  and  evaluated  with  that  from 
TSI  International,  “Trading  Partner  PC”  selected  for  installation. 

•  Following  evaluation,  MCI  Government  Systems  was  selected  as  the  Value  Added 
Network  and  contract  signed. 

•  EDI  functionality  with  the  CRAMTD  plant  database  established  for  Key  Business 
Transactions. 

•  Outgoing  EDI  code  850  -  Purchase  Order  transaction  was  demonstrated  at  the  March 
1995,  CRAMTD  Annual  Contract  Briefing. 
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3.0  Short  Term  Project  Activities 


3.1  STP  Phase  I  Tasks 

3.1.1  Current  Business  Practices  (Task  3.3.1.!^ 

Because  of  its  many  technical  requirements,  many  organizations  approach  EDI  from  a  purely 
technical  standpoint.  It  is  quite  common  to  see  EDI  implementations  fall  completely  under  the 
realm  of  MIS  departments.  According  to  most  case  studies  and  experiences,  EDI  affects  all  areas 
of  an  organization  because  it  profoundly  changes  the  way  companies  do  business.  R.H.  Baker  in 
“EDI,  What  Managers  Need  to  Know  About  the  Revolution  in  Business  Communication”,  TAB 
Books,  1991,  cites  a  number  of  areas  that  are  affected  by  EDI  implementation:  Accounting, 
Purchasing,  Sales,  Legal,  Production  Planning,  Engineering,  Warehousing,  and  Top 
Management.  Technical  Working  Paper  TWP  95,  “Electronic  Data  Interchange:  Introduction, 
Concepts  and  Examples”  (Appendix  4.2)  describes  EDI  implementation  and  presents  two 
examples:  two  commercial  trading  partners,  and  Government  bidding. 

3.1.2  Existing  EDI  Hardware/Software  ITask  3.3.1.21 

EDI  requires  many  basic  components  that  work  together  to  extract,  package  and  transmit  EDI 
messages.  TWP  95  (Appendix  4.2)  gives  an  overview  of  the  basic  software,  hardware  and 
communications  components  required  to  perform  EDI  transactions. 

The  EDI  Software  components  consist  of  Database,  Extract  Software  Utilities,  Translation 
Software,  Data  Communications  Software,  Insert  Software  Utilities  and  Batch  Control  Software. 

The  EDI  Hardware  and  Network  Requirements  consist  of  a  Computer,  Modem,  and  a  Value 
Added  Network  (VAN)  Service. 

3.2  STP  Phase  TT  Tasks 

3.2.1  Acquire  Hardware/Software  (Task  3.3.2.11 

3.2.1. 1  EDT  Translation  Software  Selection 

Several  EDI  translation  software  packages  were  considered.  Following  the  CRAMTD 
exhibit  at  the  DPSC  sponsored  EDI  Conference  and  Trade  Show,  October,  1994,  several  of  the 
EDI  component  vendors  were  contacted  and  demonstration  software  and  additional  literature  was 
obtained.  The  evaluation  techniques  reported  in  Technical  Working  Paper  (TWP)  #98, 
“Electronic  Data  Interchange:  EDI  Translation  Software  Evaluation”,  were  employed  as  an  aid  to 
selecting  the  software  most  appropriate  to  our  needs.  For  a  detailed  discussion  of  the  technical 
and  non-technical  criteria,  please  refer  to  TWP  #98  (Appendix  4.3). 

In  the  CRAMTD  Demonstration  Facility,  the  development  and  production  computers  are 
Intel  486  class  using  the  Microsoft  DOS/Windows  operating  system.  Candidate  EDI  translation 
software  was  therefore  limited  to  that  which  could  be  implemented  on  the  “PC”  platform, 
excluding  software  packages  based  on  mainframe  or  mini  computer  platforms. 
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Two  complete  software  packages  were  obtained  and  during  a  trial  period  evaluated  according 
to  the  following  criteria; 

Table  1;  EDI  Translation  Software,  Technical  Criteria  Weighting 


Technical  Criteria  Level  Weight 


Standard  Support  and  Compliance  1  0.2 


X 12  and/or  EDIFACT  2  0.5 


Version  Support  2  0.5 


Processing  Architecture  1  0.05 


Hardware/Operating  System  Support  1  0.1 


Communications  1  0.05 


Security  1  0.1 


Documentation  1  0.1 


User  Interface  1  0.1 


Scheduler  1  0.1 


Reporting  1  0.1 


Error  Handling  1  0.1 


Table  2:  EDI  Translation  Software,  Non-Technical  Criteria  Weighting 


Non-Technical  Criteria 


Software  Costs 


Translation  Engine 


Transaction  Sets 


Communications 


Mapping 


Scheduler 


Maintenance 


Technical  Support 


Hours  of  Operation 


Quality  of  Staff 


Extra  Charges 


Vendor  Attributes 


Market  Share 


Years  in  Business 


Innovations 


Experience 
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The  raw  Scores  (RS)  and  weighted  scores  (WS)  for  the  two  software  vendors  (VI  and  V2) 
are  given  in  the  following  two  tables: 


Table  3:  EDI  Translation  Software,  Technical  Criteria  Scores 


Vendor  1 

Vendor  2 

Technical  Criteria 

Raw 

Weight 

Raw 

Weight 

Standards  Support  and  Compliance 

2.0 

1.8 

Processing  Architecture 

9 

0.45 

7 

0.35 

Hardware/Operating  System  Support 

8 

0.8 

8 

0.8 

Communications 

8 

0.4 

7 

0.35 

Security 

9 

0.9 

5 

0.5 

Documentation 

9 

0.9 

5 

0.5 

User  Interface 

10 

1.0 

7 

0.7 

Scheduler 

9 

0.9 

9 

0.9 

Reporting 

10 

1.0 

10 

1.0 

Error  Handling 

8 

0.8 

8 

0.8 

Technical  Criteria  Weighted  Score  Total 

9.15 

7.70 

Table  4:  EDI  Translation  Software,  Non-Technical  Criteria  Scores 


Vendor  1 

Vendor  2 

Technical  Criteria 

Software  Costs 

9.3 

4.65 

9.6 

4.8 

Technical  Support 

9.0 

2.7 

8.0 

El 

Vendor  Attributes 

8.4 

1.68 

8.5 

Non-Technical  Criteria  Weight  Score  Total 

9.03 

8.9 

As  illustrated  in  the  Technical  and  Non-Technical  criteria  tables,  Vendor  I's  superior  user 
interface  (Microsoft  Windows  based),  security  (multilevel,  role  based)  and  documentation  gave  it 
the  edge  over  Vendor  2's  software.  The  ease  of  use  of  the  Microsoft  Windows  based  interface 
represents  a  significant  criteria  when  using  EDI  software  in  practice.  Additional  points  were 
scored  for  their  timely  and  free  distribution  of  new  EDI  translation  set  versions  and  the  built-in 
telecommunications  software. 

Vendor  1  in  this  case  is  TSI  International  and  their  software  package  is  called  Trading  Partner 
PC.  They  have  been  in  the  EDI  business  12  years  and  work  extensively  with  many  government 
agencies.  Version4.40  of  Trading  Partner  PC  was  purchased  in  June  1995. 
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Installation  of  the  software  was  very  straightforward,  consisting  of  the  following  steps: 

1)  Run  the  Windows  based  SETUP.EXE  program  that  comes  on  the  installation  disk. 

2)  Choose  a  directory  into  which  to  install  the  main  software. 

3)  Choose  a  directory  to  install  the  EDI  transaction  sets. 

4)  Choose  the  EDI  transaction  sets  and  versions  to  be  used.  This  procedure  installs 
templates  for  each  of  the  transaction  sets  selected  by  the  user. 

After  installing  the  EDI  translation  software,  we  configured  two  new  “trading  partners”,  one 
for  DPSC  and  one  for  CRAMTD.  Each  “trading  partner”  is  represented  as  an  icon  on  the  main 
screen.  Configuring  a  “trading  partner”  requires  the  following  information  be  provided: 

1)  The  name  of  the  trading  partner. 

2)  A  unique  EDI  identification  number  for  the  trading  partner  such  as  a  DUNS  number. 

3)  A  set  of  EDI  transactions  with  which  the  trading  partner  will  work. 

4)  The  port  and  hardware  address  of  the  modem  used  to  communicate  between  the  trading 
partner  and  the  Value  Added  Network  (VAN). 

3.2.1.2  Value  Added  Network  Selection 

As  discussed  in  Technical  Working  Paper  TWP  #95,  a  Value  Added  Network  (VAN)  service 
provides  a  mailbox  into  which  EDI  transactions  can  be  stored  and  forwarded  to  and  from  trading 
partners.  In  order  to  exchange  EDI  transactions,  two  trading  partners  must  have  mailboxes  on 
the  same  VAN  or  on  VAN  services  that  offer  a  connecting  gateway. 

As  with  the  EDI  translation  software,  a  systematic  approach  was  taken  to  choosing  a  VAN 
service  provider.  At  the  EDI  trade  show  in  Philadelphia  in  October  1994,  we  were  able  to  meet 
several  VAN  service  providers.  Our  main  criteria  for  a  VAN  service  were: 

1 .  Connectivity  with  DPSC  in  Philadelphia.  This  is  perhaps  the  most  important  criteria 
because  of  the  goals  of  the  Short  Term  Project. 

2.  Experience  and  expertise  with  EDI.  We  wanted  to  contract  with  a  provider  with 
significant  prior  experience  with  EDI  and  the  expertise  such  experience  brings. 

3.  Cost.  We  were  somewhat  conscious  of  cost,  especially  fixed  monthly  fees  as  our 
transaction  volume  would  not  be  high.  Most  VAN  services  are  billed  in  a  similar  fashion 
to  telephone  service  with  a  fixed  monthly  service  fee  and  an  additional  fee  based  on 
usage.  In  the  case  of  VAN  service,  the  variable  portion  is  tied  to  the  amount  of  EDI  data 
transferred. 

4.  Fault  Tolerance.  Services  that  offered  alternate  operating  procedures  in  the  event  of 
system  failure  or  other  down  time  were  especially  considered. 
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5.  Gateways  to  other  VANs.  For  future  expansion  and  trading  opportunities,  we  also 

wanted  to  consider  whether  a  given  service  provider  had  gateways  set  up  to  other  VANs. 

After  considering  several  service  providers,  we  decided  on  MCI  Government  Systems.  The 
compelling  reasons  included: 

1 .  Had  prior  experience  with  U.S.  Government  EDI  contracts  including  DPSC  in 
Philadelphia. 

2  Significant  experience  and  expertise  with  EDI.  Also  worked  closely  with  our  chosen  EDI 
software  from  TSI. 

3 .  Relatively  low  fixed  monthly  costs. 

4.  Dual  operating  centers  spread  out  over  the  United  States. 

5.  Gateways  to  other  VANs  including  AT&T’s  Easy  Link  services,  another  major  VAN 
provider. 

We  signed  a  one-year  contract  for  VAN  services. 

3.2.2  CIM  Integration  (3.3.2.21 

Once  the  EDI  translation  software  and  VAN  service  were  obtained,  we  started  to  work  on 
integrating  the  EDI  functionality  with  the  CRAMTD  plant  database.  The  first  step  in  this 
integration  was  to  identify  the  EDI  transaction  sets  we  would  be  required  to  support.  The 
following  EDI  transactions  were  identified  as  key  business  transactions  that  required  the  support 
of  the  database.  Direction  shown  in  Table  5  indicates  whether  we  will  receive  (IN)  or  send 
(OUT)  these  transactions: 


Table  5:  Key  Business  Transactions 


Code 

Transaction  Set 

Direction 

1  n 

836 

Notice  of  Award  I 

IN 

840 

Request  for  Quote 

IN 

843 

Response  to  Request  for  Quote 

OUT 

850 

Purchase  Order 

IN/OUT 

856 

Advanced  Ship  Notice 

IN/OUT 

860 

Purchase  Order  Change 

IN/OUT 

865 

Purchase  Order  Change  Acknowledge 

IN/OUT 

810 

Invoice 

OUT 

997 

Functional  Acknowledge 

IN/OUT 
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The  transaction  sets  shown  above  are  not  necessarily  supported  by  all  EDI  trading  partners, 
although  the  MCI  network  (VAN)  is  capable  of  sending  any  transaction  set  from  the  X.  12 
standard.  A  trading  partner  (receiving  entity)  may  not  be  set  up  to  receive  certain  transactions 
which  it  finds  irrelevant  or  undesirable  for  conduct  of  business  based  on  EDI.  For  example, 
DPSC  Subsistence/Operational  Rations  does  not  use  set  850  (purchase  orders)  since  they 
currently  only  conduct  large  purchases  and  on  negotiated  contracts.  Other  agencies  are  restricted 
regarding  the  maximum  dollar  amounts  for  purchase  orders  via  EDI. 

For  outgoing  transactions.  Structured  Query  Language  (SQL)  scripts  are  required  to  extract 
data  from  the  plant  database  and  to  format  the  output  to  a  form  suitable  for  the  EDI  translation 
software.  The  Oracle  SQL*Plus  tool  was  used  to  carry  out  this  ftmction.  The  TSI  International 
EDI  transaction  software  periodically  scans  a  default  directory  for  any  new  extracted  output  files. 
When  it  finds  a  new  file,  a  script  within  the  TSI  software  reads  the  file  and  converts  it  to  an  EDI 
transaction  file,  connects  to  the  VAN  and  uploads  the  transaction.  This  process  can  be  entirely 
automated.  An  example  of  an  outgoing  850  -  Purchase  Order  transaction  was  demonstrated  at 
the  March,  1995  CRAMTD  Annual  Contract  Briefing. 

For  incoming  transactions,  a  slightly  different  approach  must  be  employed.  The  TSI 
International  EDI  translation  software  is  capable  of  automatically  receiving  an  incoming  EDI 
transaction  and  saving  the  enclosed  data  in  a  flat  file.  Scripts  were  written  using  the  Oracle 
SQL*Loader  tool  to  then  load  the  incoming  data  into  the  plant  database.  The  plant  database  was 
augmented  to  include  extra  tables  to  accommodate  the  incoming  EDI  transaction  data.  Based  on 
this  incoming  data,  special  scripts  must  be  created  to  extract  relevant  data  and  insert  it  into  the 
appropriate  tables  that  are  part  of  the  main  plant  database. 

3.3  STP  Phase  TTI  Tasks 
3.3.1  Demonstrate  EDl/CIM  (3.3.3.!) 

At  the  March  8, 1995  CRAMTD  Annual  Contract  Briefing,  an  example  of  an  outgoing  EDI 
code  850  transaction  “Purchase  Order”  was  demonstrated. 

During  the  performance  period  of  the  STP,  CRAMTD  was  unable  to  establish  a  Trading 
Partner  relationship  with  Subsistence  at  DPSC.  Following  the  conclusion  that  a  Subsistence 
presence  in  EDI  was  not  sufficiently  active,  discussed  a  test  relationship  with  Clothing  and 
Textiles  but  that  was  unsuccessful  due  to  a  lack  of  time. 

The  National  Institute  of  Science  and  Technology  (NIST)  pilot  EDI  effort,  similarly,  did  not 
reach  the  stage  where  participation  was  possible.  The  common  interest  was  definition  of  the  EDI 
transaction  set  for  product  description  (product  quality)  data. 

Resources  at  the  CAFT  Food  Manufacturing  Technology  Facility  (Demonstration  Site)  will 
continue  consideration  of  EDI  and  establish  a  Trading  Partner  when  feasible. 
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3.3.2  Identify  Technology  Transfer  Partners  (3.3.3.2^ 

TSI  International  has  been  in  the  EDI  business  12  years  and  their  Trading  Partner  PC 
software  was  implemented  at  the  Demonstration  Site.  MCI  Government  Systems  was  selected  as 
the  Value  Added  Network  (VAN)  resource.  MCI  has  prior  experience  with  Government  EDI 
contracts  including  with  DPSC. 

3.3.3  Provide  Technical  Guidance  13.3.3.3^ 

Two  Technical  Working  Papers  were  prepared  and  distributed:  “Electronic  Data  Interchange; 
Introduction,  Concepts  and  Examples”  (TWP  95)  and  “Electronic  Data  Interchange:  EDI 
Translation  Software  Evaluation”  (TWP  98). 

At  such  time  as  active  Trading  Partner  relationships  are  closer  to  being  established  in 
Operational  Rations,  the  CAFT  Food  Manufacturing  Technology  Facility  (Demonstration  Site) 
can  provide  workshops.  In  concert  with  DPSC  Procurement  activities,  the  Demonstration  Site 
under  CORANET  DEMO  and  a  CORANET  Short  Term  Project  can  also  undertake  a  proactive 
role  in  supporting  Combat  Ration  Producers  becoming  Trading  Partners  to  DPSC.  The  Vendor 
Evaluation  System  (see  Final  Technical  Report  FTR  20.0,  “Vendor  Evaluation  System”,  STP 
#60.  Available  from  The  Center  for  Advanced  Food  Technology,  120  New  England  Avenue, 
Piscataway,  NJ  08854,  Phone  (908)  445-6130,  FAX  (908)  445-6145)  will  also  require  electronic 
transfer  of  information.  Establishing  a  capability  for  such  transfers  should  maximize 
compatibility  between  hardware  and  software  requirements. 
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4.0  Appendix 


4.1  Figure  1  CRAMTD  STP  #22  Time  and  Events  Milestones 

4.2  Technical  Working  Paper  (TWP)  95,  “Electronic  Data  Interchange:  Introduction, 
Concepts  and  Examples” 

4.3  Technical  Working  Paper  (TWP)  98,  “Electronic  Data  Interchange:  EDI  Translation 
Software  Evaluation” 
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1  Introduction 


Most  companies  operating  in  the  world  today  make  use  of  paper  documents  that 
represent  binding  contracts  to  provide  goods  and  services  to  other  organizations  and 
individuals.  It  has  been  recognized  that  although  information  systems  can  be  of 
tremendous  benefit  to  storing  and  cataloging  the  data  from  such  documents,  the 
exchange  of  business  documents  is  still  prone  to  mishandling,  delivery  delays  and 
data  entry  errors. 

Electronic  Data  Interchange  (EDI)  is  the  term  given  to  the  exchanging  of  business 
documents,  by  standardized  electronic  means,  between  trading  partners.  The  use  of 
EDI  has  been  credited  with  reducing  delivery  times  and  data  entry  errors  by  elimi¬ 
nating  the  need  for  human  intervention  for  most  of  the  common  business  transactions 
[Emm90] . 

This  paper  is  designed  to: 

1.  Give  an  introduction  to  EDI  concepts  and  terminology; 

2.  Give  some  examples  of  actual  EDI  message  exchanges; 

3.  Provide  some  guidelines  for  first  time  users  of  EDI  and  those  who  may  be 
planning  to  implement  EDI  in  their  organization;  and 

4.  Provide  a  collection  of  resources  for  individuals  who  would  like  to  find  out  more 
about  EDI. 

2  EDI:  History  and  Definitions 

Typical  business  uses  for  computers  include  the  entry,  storage,  retrieval  and  printing 
of  data  that  is  critical  for  the  operations  of  the  business.  Purchase  Orders,  Customer 
Orders,  Invoices,  Shipping  and  Receiving  and  other  information  is  typically  entered 
by  a  human  operator  and  stored  on  a  computer  system.  Later  this  same  information 
may  be  printed  out,  placed  in  an  envelope  and  mailed  to  another  company.  Once  at  its 
destination,  the  envelope  is  opened,  the  contents  removed  and  finally,  the  information 
is  read  off  of  the  document  and  entered  into  another  computer  system.  Such  exchanges 
are  carried  out  countless  times  each  day  all  over  the  world. 

There  are,  however,  some  inherent  problems  with  these  procedures.  For  example: 

1.  Information  must  be  entered  at  least  twice;  once  by  the  originating  company 
and  once  by  the  destination  company. 

2.  Data  entry  is  prone  to  human  error. 

3.  Exchanging  paper  documents  takes  on  the  order  of  days  by  regular  mail  or  at 
least  overnight  by  costly  express  mail. 

4 


Each  of  these  problems  results  in  time  delays  for  processing  paper  documents. 
Such  delays  result  in  uncertainty  for  production  planning,  poor  customer  service  and 
inflated  inventories  (buffers)  required  to  cover  for  inaccurate  or  untimely  data  [SS92]. 

In  the  1960s,  these  shortcomings  began  to  gain  attention  as  large  manufacturers 
in  the  U.S.  auto  industry  and  international  shipping  companies  began  to  see  their 
industries  burgeon.  For  a  large  auto  maker  with  hundreds  or  thousands  of  parts 
suppliers,  managing  all  of  the  outgoing  purchase  orders  and  incoming  invoices  soon 
became  a  mammoth  task.  It  was  in  the  1960s  when  the  transportation  industry  began 
to  form  some  standards  for  the  exchange  of  these  common  business  documents  via 
communication  networks. 

The  first  standards  created  were  aimed  at  standardizing  the  documents  used 
within  particular  industries.  These  included  transportation  and  financial  services. 
By  the  end  of  the  1960s,  however,  it  was  discovered  that  many  similarities  existed 
across  these  and  other  industries  giving  rise  to  interest  in  national  standards  [Dat93]. 

Since  the  1970s,  the  American  National  Standards  Institute  (ANSI)  has  managed 
the  creation  and  maintenance  of  EDI  standards  though  the  Accredited  Standards 
Committee  (ASC)  group  designated  as  X12.  In  1985,  a  world-wide  effort  to  stan¬ 
dardize  EDI  transactions  was  formalized  when  the  United  Nations  formed  the  Elec¬ 
tronic  Data  Interchange  for  Administration,  Commerce  and  Transport  (EDIFACT) 
committee  [Can93].  Additional  details  of  these  two  standards  groups  are  given  in 
sections  5.1  and  5.2. 

2.1  Definitions  of  EDI 

Although  most  individuals  agree  on  the  basic  concepts  behind  EDI,  there  have  been 
many  definitions  put  forth  to  describe  it.  Here  are  a  few  examples: 

•  “EDI  is  the  exchange  of  routine  business  transactions  in  a  computer-processable 
format,  covering  such  traditional  applications  as  inquiries,  planning,  purchasing, 
acknowledgements,  pricing,  order  status,  scheduling,  test  results,  shipping  and 
receiving,  invoices,  payments,  and  financial  reporting.”  [Dat93] 

•  “The  standards  based  computer-to-computer  exchange  of  intercompany  busi¬ 
ness  documents  and  information.”  [Coa88] 

•  “...computer-to-computer  transmission  of  standard  business  data.”  [Emm90] 

•  “EDI  is  defined  as  the  exchange  of  computer  processable  data  in  a  standard 
format  between  organizational  entities.”  [GT94] 

•  “Electronic  data  interchange  (EDI)  is  the  computer-to-computer  exchange  of 
routine  business  information  using  Accredited  Standards  Committee  (ASC)  X12 
standards.”  [HH93] 
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Several  things  are  clear  from  these  examples  of  EDI  definitions.  The  business 
transactions  must  indeed  be  in  some  common  or  standard  format  such  that  they  can 
be  automatically  processed  by  computer  applications.  What  is  also  implied  is  that 
human  intervention  should  not  be  required  in  order  to  process  the  documents.  It 
is  also  clear  that  the  business  documents  themselves  have  some  commonality  across 
most  if  not  all  industries.  For  example,  the  purpose  and  structure  of  an  invoice 
should  be  agreed  upon  by  all  business  hoping  to  exchange  invoices  electronically  via 
computer  applications. 

What  is  not  clear  from  these  definitions  is  the  various  hardware  and  software 
components  required  to  make  EDI  work.  These  components  will  be  discussed  in 
section  4  starting  on  page  10. 

2.2  EDI  Benefits  to  Business 

It  would  be  difficult  to  justify  the  adoption  of  EDI  without  some  quantitative  and 
qualitative  benefits  to  the  organization.  The  following  benefits  are  described  in  a 
general  fashion  as  companies  may  perceive  such  benefits  to  different  degrees.  Most  of 
the  general  business  literature  on  EDI  supports  these  claims. 

2.2.1  Quantifiable  Benefits  to  Business 

All  of  the  following  benefits  of  using  EDI  lead  to  cost  savings  either  directly  or  in¬ 
directly  through  reduced  man-hour  requirements  (summarized  from  [SS92],  [Dat93] 
and  [HH93]). 

•  Using  EDI  shortens  the  processing  time  for  incoming  and  outgoing  business 
documents. 

•  Using  EDI  lowers  requirements  for  paper,  printing  supplies  and  postage. 

•  Using  EDI  recduces  costs  for  storage  and  filing. 

•  Using  EDI  lowers  requirements  for  the  number  of  data  processing  and  clerical 
staff  such  as  order  entry  personnel. 

•  Using  EDI  increases  the  quality  of  the  data  in  information  systems.  Data  entry 
errors  are  eliminated. 

•  Using  EDI  can  allow  for  lower  inventory  levels  to  be  maintained  since  ordering 
cycles  are  much  shorter. 
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2.2.2  Qualifiable  Benefits  to  Business 

The  quantifiable  benefits  listed  above  may  lead  to  the  following  benefits  for  an  orga¬ 
nization  that  adopts  EDI. 

•  Better  customer  response  [SS92].  Customers  can  receive  better  quality  infor¬ 
mation  such  as  order  or  delivery  status. 

•  Uniform  communications  with  all  trading  partners  [Dat93].  Fewer  but  more 
robust  avenues  of  communication  may  simplify  communications.  For  example, 
the  U.S.  Department  of  Defense  (DoD)  has  made  steps  to  move  to  completely 
automated  bidding  and  contact  negotiation  systems  using  EDI  [HH93]. 

•  Increased  business  opportunities.  When  dealing  with  government  contracts,  Re¬ 
quests  for  Quotations  (RFQs)  are  frequently  distributed  to  potential  suppliers. 
Receiving  RFQs  electronically  via  EDI  can  allow  a  supplier  to  evaluate  more 
RFQs  and  to  generate  bids  in  response  [HH93]. 

There  are  many  “success  stories”  that  have  been  printed  about  EDI.  Summaries 
of  a  few  of  these  are  given  here; 

•  (This  example  is  taken  from  [Bak91])  An  early  adopter  and  EDI  vanguard,  the 
General  Motors  Corp.  (GM)  began  exchanging  electronic  purchase  orders  with 
one  of  its  largest  parts  suppliers,  PPG,  in  the  1960s.  Today  EDI  transactions 
based  on  ANSI  ASC  X12  standards  are  exchanged  on  a  regular  basis  with  over 
6,000  customers  in  26  countries.  The  following  benefits  have  been  realized; 

—  Cut  payment  cycle  by  eight  to  ten  days. 

-  Payments  disputes  dropped  to  less  than  4%  and  disputes  take  much  less 
time  to  resolve. 

-  Payments  are  made  almost  immediately.  There  is  no  need  to  wait  until 
the  following  “billing  cycle.” 

A  GM  subsidiary.  Electronic  Data  Systems  (EDS)  is  now  in  the  business  of 
supporting  EDI  systems  worldwide  [Bak91]. 

•  (This  example  is  taken  from  [HS91])  The  Norwegian  customs  clearance  system 
called  TVINN  (Tollekspedisjon  Ved  INNfprselor  “customs  clearance  at  import”) 
uses  UN/EDIFACT  EDI  messages  to  streamline  the  paperwork  required  for 
importing  goods.  The  system  allows  customs  clearance  documents  to  be  filed 
electronically  via  EDI  messages.  The  system  has  been  running  since  1988  and 
has  provided  the  following  benefits  in  reference  to  the  handling  of  customs 
clearance  documentation  [HS91]; 
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-  Reduction  in  customs  clearance  document  handling  time. 

—  Improvement  in  failure  control  when  customs  documentation  is  incomplete 
or  erroneous. 

—  Reduction  in  document  handling  and  storage  costs. 

•  According  to  Peter  Wayner,  a  consulting  editor  for  BYTE  magazine:  ’‘An  inter¬ 
nal  study  by  a  Fortune  500  firm  showed,  for  example,  that  the  company  could 
save  $500  to  $700  million  with  a  corporate- wide  EDI  system”  [Way94]. 

3  EDI  Implementation  Methodology 

Implementing  EDI  requires  more  than  simply  installing  some  computer  hardware 
and  software.  Proper  planning  and  testing  of  systems  and  procedures  is  required  to 
increase  the  chances  for  success  and  to  achieve  the  potential  benefits  described  in 
previous  sections.  This  section  of  the  paper  will  provide  a  step  by  step  approach  to 
preparing,  planning,  testing  and  installing  an  EDI  system. 


3.1  Business  Issues 

Because  of  its  many  technical  requirements,  many  organizations  approach  EDI  from 
a  purely  technical  standpoint.  It  is  quite  common  to  see  EDI  implementations  fall 
completely  under  the  realm  of  MIS  departments.  According  to  most  case  studies  and 
experiences,  EDI  affects  all  areas  of  an  organization  because  it  profoundly  changes 
the  way  companies  do  business.  Baker  cites  several  areas  that  are  affected  by  EDI 
implementation  ([Bak91]  page  77): 

•  Accounting 

•  Purchasing 

•  Sales 

•  Legal 

•  Production  Planning 

•  Engineering 

•  Warehousing 

•  Top  Management 

The  guidelines  presented  below  take  these  diverse  groups  into  account  when  plan¬ 
ning  an  EDI  implementation. 
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3.2  Implementation  Steps 

The  successful  implementation  of  an  EDI  project  can  be  broken  down  into  four  main 
stages:  Planning,  Acquisition  and  Development,  Pilot  and  Full  Implementation.  Of 
the  four,  the  planning  stage  is  the  most  critical  and  may  actually  take  the  longest 
time  to  complete. 

3.2.1  The  Planning  Stage 

The  Planning  stage  is  where  all  of  the  background  research  into  the  organizational 
and  technical  impact  of  EDI  is  conducted.  Because  of  EDPs  profound  effect  on  an 
organization  (see  previous  section)  consideration  must  be  paid  to  all  of  the  areas  that 
may  be  affected  by  an  EDI  implementation. 

Some  of  the  action  items  to  be  carried  out  in  the  planning  stage  include: 

•  Diagram  the  current  flow  of  paper  documents  in  and  out  of  the  organization. 
Identify  as  many  “paper  trails”  as  possible.  Indicate  which  departments  and 
personnel  are  responsible  for  “touching”  these  documents  as  they  pass  through 
the  organization.  Also  indicate  where  appropriate  controls  are  in  place  or  need 
to  be  added.  For  example  purchase  orders  may  not  leave  the  organization  unless 
signed  by  a  purchasing  manager. 

Identifying  these  paper  trails  should  shed  light  on  potential  areas  where  EDI 
can  benefit  the  most.  If  appropriate  controls  need  to  be  added,  do  so  right  away. 
EDI  is  not  a  fix  for  whatever  problems  may  exist  in  the  current  paper  flow. 

•  Identify  key  personnel  along  the  current  paper  trails.  Be  aware  that  the  per¬ 
sonnel  requirements  for  certain  tasks,  such  as  order  entry,  will  be  reduced  con¬ 
siderably  while,  in  other  areas,  new  jobs  may  be  created. 

It  is  important  to  deal  with  these  ramification  before  they  become  “political 
issues”  [Bak91]. 

•  Identify  the  training  and  re-training  requirements  for  the  organization.  New 
tasks  will  need  to  be  performed  by  current  personnel.  Assume  that  all  related 
personnel  will  require  some  degree  of  training  in  new  procedures. 

•  Make  a  list  of  potential  EDI  trading  partners.  Visit  their  sites  and  learn  how 
committed  they  are  to  doing  business  via  EDI.  Rank  this  list  in  order  of  EDI 
competency.  Those  trading  partners  at  the  top  of  the  list  will  be  potential 
candidates  for  the  Pilot  stage. 

•  Gather  the  technical  requirements  for  hardware,  software  and  networking.  These 
choices  may  be  dictated  by  existing  systems  already  in  place  and  may  be  oth¬ 
erwise  influenced  by  the  software  and  communications  networking  choices  (i.e.. 
Value  Added  Network  provider  (VAN))  made  by  potential  trading  partners. 

Other  considerations  can  be  found  in  [HH93]. 
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3.2.2  The  Acquisition  and  Development  Stage 

In  this  stage,  the  hardware  and  software  components  are  chosen  based  on  requirements 
taken  from  the  planning  stage  and  hardware  and  software  supplier  evaluations.  The 
actual  components  required  to  make  EDI  work,  including  the  basic  features  of  EDI 
translation  software,  are  discussed  in  section  4  of  this  technical  working  paper  starting 
on  page  10.  The  methodology  and  criteria  for  selecting  EDI  translation  software,  a 
major  component  of  any  EDI  implementation,  will  be  given  in  another  technical 
working  paper. 

Any  utilities,  such  as  extract  and  insert  routines,  that  need  to  be  written  in-house, 
are  also  created  during  this  stage. 

At  the  end  of  this  stage,  the  software  and  hardware  components  should  be  installed 
and  operational.  Testing  must  be  done  to  ensure  that  all  utilities  perform  correctly 
and  that  communications  with  the  Value  Added  Network  provider  or  direct  links  to 
trading  partners  work  as  planned. 

3.2.3  The  Pilot  Stage 

During  the  Pilot  stage,  EDI  transactions  are  carried  out  with  one  or  two  trading 
partners.  Ideally,  the  first  trading  partners  will  have  prior  EDI  experience.  This  can 
be  a  great  help  in  ironing  out  compatibility  issues,  software  bugs  and  other  procedural 
issues.  Contingency  plans  should  be  made  in  the  event  EDI  transactions  are  lost  or 
corrupted  in  transmission. 

During  this  time,  all  other  systems  are  run  in  parallel  with  EDI.  For  example, 
order  entry  functions  should  continue  as  before.  This  support  is  necessary  since  the 
majority  of  other  trading  partners  will  still  be  submitting  paper  documents.  EDI 
implementations  are  very  rarely  “cut-over”  from  paper  based  to  electronic  based 
exchanges  in  one  step. 

3.2.4  The  Full  Implementation  Stage 

If  all  goes  well  in  the  Pilot  stage,  more  trading  partners  can  be  added,  usually  one 
at  a  time.  During  this  time,  the  level  of  support  required  for  incoming  and  outgoing 
paper  documents  should  begin  to  fall  off. 

Once  again,  attention  must  be  paid  to  the  organizational  changes  that  occur  as 
less  emphasis  is  placed  on  the  handling  of  paper  documents. 


4  EDI  Basic  Components 


EDI  requires  many  basic  components  that  work  together  to  extract,  package  and 
transmit  EDI  messages.  In  some  systems,  the  functionality  of  these  components  are 
combined  in  one  subsystem.  This  section  is  intended  to  give  an  overview  of  the 
basic  software,  hardware  and  communications  components  required  to  perform  EDI 
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Figure  1;  Flow  of  Data  showing  EDI  Components 

transactions.  For  a  concrete  example  of  EDI  using  these  components  please  refer  to 
section  6  starting  on  page  22. 

4.1  EDI  Software  Components 

The  following  section  contains  descriptions  of  the  software  components  and  their 
purpose  in  an  EDI  system.  Many  businesses  will  already  have  some  of  the  software 
components,  such  as  a  database,  already  in  place.  Other  software  components  must  be 
purchased  from  commercial  sources  or  written  by  the  organization’s  MIS  or  computer 
programming  staff. 

Figure  1  gives  a  general  outline  of  the  flow  of  data  through  an  EDI  system. 

Database  Each  trading  partner  should  maintain  a  database  capable  of  storing  data 
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corresponding  to  the  business  documents  they  wish  to  exchange.  For  example, 
a  purchasing  database  will  contain  tables  capable  of  storing  purchase  order 
header  information,  purchase  order  detail  information,  parts  and  product  lists 
and  company  information  for  each  trading  partner. 

A  database  will  also  require  some  data  entry  screens  that  allow  users  to  enter 
and  retrieve  data  from  the  database.  For  example,  a  data  entry  screen  that 
enables  a  user  to  look  up  and  change  current  product  prices  would  be  necessary. 
Reporting  capabilities  are  also  required  to  produce  larger  collections  of  data  that 
can  be  viewed  on  screen  or  printed  out.  For  example,  a  monthly  report  might 
be  created  showing  the  number  of  customer  orders  received  broken  down  by 
product  number. 

Databases  can  be  created  using  a  variety  of  commercial  database  development 
tools  such  as  Paradox,  FoxPro,  Access,  Approach,  Clipper,  dBase,  Oracle, 
Sybase,  Ingres,  DB/2  and  others  (Note:  All  trademarks  of  their  respective 
companies).  Such  software  ranges  in  cost  from  a  few  hundred  dollars  for  PC 
databases  to  hundreds  of  thousands  of  dollars  for  mainframe  databases. 

Extract  Software  Utilities  These  software  utilities  are  capable  of  extracting  data 
from  the  database  tables  into  specially  formatted  flat  ASCII  files.  This  is  done 
in  preparation  for  the  translation  step.  Typically,  such  utilities  are  included 
with  commercial  database  software  tools.  It  is  also  possible  that  a  utility  will 
have  to  be  custom  programmed  to  accomplish  the  task.  Often  it  is  necessary 
to  have  a  different  extract  utility  for  each  type  of  transaction  to  be  exchanged. 

Extract  (and  Insert)  software  is  sometimes  referred  to  as  Mapping  software 
because  it  maps  the  data  in  the  company  database  to  specific  fields  in  an  EDI 
transaction.  For  example,  in  a  purchasing  database,  the  purchase  order  number 
is  mapped  to  the  appropriate  location  in  the  EDI  transaction  file.  Typically  the 
job  of  mapping  a  database  to  various  EDI  transactions  is  done  only  once.  The 
results  of  this  step  are  then  used  to  generate  the  extract  and  insert  software 
utilities. 

Translation  Software  For  outgoing  messages,  the  translation  software  reads  in  a 
flat  ASCII  file  extracted  from  the  database  and  writes  out  an  EDI  transaction 
file  that  contains  all  of  the  special  data  element  and  segment  delimiters  that 
correspond  to  the  transaction  set. 

For  incoming  messages,  the  translation  software  reads  in  an  EDI  transaction 
file,  strips  the  EDI  specific  codes  off  of  the  file  and  writes  a  flat  ASCII  file 
suitable  for  an  insert  utility  to  use  as  input. 

These  actions  rely  on  adherence  to  the  EDI  standards  (ANSI  ASC  X12  or 
EDIFACT)  to  perform  the  translation.  Often  the  translations  are  carried  out 
with  slightly  different  codes  depending  on  the  individual  needs  of  the  trading 
partner. 
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Some  translation  software  packages  can  perform  the  job  of  the  extract  and  insert 
software  utilities  as  well  as  the  translation  functions. 

Data  Communications  Software  This  software  is  responsible  for  connecting  the 
organization’s  computers  to  a  remote  host  or  Value  Added  Network  (VAN)  and 
for  uploading  or  downloading  messages  to  and  from  the  trading  partner  or  VAN 
mailbox  (described  below). 

Insert  Software  Utilities  These  utilities  get  their  input  from  the  flat  ASCII  file 
produced  by  the  translation  software  after  an  incoming  message  has  arrived. 
These  utilities  perform  the  reverse  job  of  the  extract  software  utilities  in  that 
they  take  data  from  the  ASCII  files  and  insert  the  data  into  the  database. 

Batch  Control  Software  Although  this  software  component  is  optional,  most  sys¬ 
tems  include  some  type  of  batch  control  to  coordinate  the  extract,  translate  and 
data  communications  steps.  This  software  may  also  include  timers  that  trigger 
the  execution  of  these  steps  at  user  defined  intervals  during  the  day.  For  exam¬ 
ple,  a  user  could  set  the  communications  software  to  dial  up  the  VAN  mailbox 
and  download  any  new  EDI  messages  every  two  hours. 


4.2  EDI  Hardware  and  Network  Requirements 

The  software  systems  described  above  rely  on  computer  and  telecommunications  hard¬ 
ware  to  help  carry  out  the  exchange  of  EDI  messages.  There  are  many  computer  hard¬ 
ware  systems  on  the  market  and  an  exhaustive  presentation  is  beyond  the  scope  of 
this  paper.  The  following  is  a  general  description  of  the  various  hardware  components 
required. 

Computing  Platform  In  the  1960s  and  1970s,  mainframes  and  minicomputers  were 
used  to  run  the  database,  extract/insert  utilities,  EDI  translation  software  and 
communications  software.  This  is  still  feasible  today  and  many  companies  op¬ 
erate  in  this  fashion. 

In  the  late  1970s  and  1980s,  the  personal  computer  (PC)  market  began  to  accel¬ 
erate  giving  inexpensive  processing  power  in  affordable  and  manageable  pack¬ 
ages.  For  small  businesses,  personal  computers  attached  to  local  area  networks 
(LAN)  are  the  mainstay  of  the  business.  There  are  many  EDI  translators  and 
database  products  that  operate  on  a  PC  platform.  For  companies  just  starting 
up  or  for  those  with  limited  budgets  for  EDI  hardware,  PCs  make  an  excellent 
choice. 

In  many  cases,  the  existing  computer  hardware  will  dictate  the  choices  in  future 
computer  and  software  purchases.  A  company  that  is  perfectly  happy  with  their 
minicomputer  will  tend  to  develop  EDI  applications  on  the  same  machine. 
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Figure  2:  Trading  Partner  to  Trading  Partner  Direct  Network  Connections 

A  detailed  comparison  of  the  features  and  merits  of  the  various  computer  plat¬ 
forms  is  beyond  the  scope  of  this  paper. 

Communications  Equipment  Communications  equipment  is  used  to  link  an  or¬ 
ganization’s  computers  to  either  a  Value  Added  Network  (VAN)  provider  or 
directly  to  trading  partners  for  the  purposes  of  transmitting  and  receiving  EDI 
transaction  messages. 

In  either  case  (VAN  or  direct  connection),  a  modem  (MODulator  DEModula- 
tor)  is  employed.  Modems  are  capable  of  converting  the  digital  signals  produced 
by  a  computer  into  analog  signals  that  can  be  transmitted  across  telephone  lines, 
A  modem  at  the  other  end  then  converts  the  analog  signals  back  to  digital  form. 

Figure  2  shows  the  direct  connection  (called  point-to-point)  between  two  trading 
partners  using  modems  and  an  ordinary  phone  line.  This  setup  has  the  advan¬ 
tage  of  low  cost  because  no  “middle  man”  (the  VAN)  is  used  to  temporarily 
store  the  EDI  transactions  (please  see  the  following  example).  However,  it  is 
possible  that  when  trading  partner  A  attempts  to  connect  with  trading  partner 
B,  another  party  is  in  the  process  of  sending  some  transactions.  In  this  case 
trading  partner  A  will  literally  receive  a  “busy  signal”  and  will  have  to  try  again 
at  a  later  time. 

Another  shortcoming  of  this  point-to-point  method  of  communicating  is  the 
problem  of  configuring  possibly  incompatible  modems.  As  more  trading  part¬ 
ners  wish  to  exchange  EDI  transactions,  the  number  of  possible  connections 
(and,  hence  conflicts)  grows  dramatically. 

4.3  Value  Added  Network  Services 

Value  Added  Network  (VAN)  services  such  as  VAN  Mailboxes  can  be  used  to  alleviate 
some  of  the  problems  encountered  with  the  point-to-point  connection  described  in  the 
previous  example.  When  used  for  the  purposes  of  EDI,  VANs  can  provide  Mailboxes 
that  are  capable  of  storing  electronic  mail  and  EDI  transactions.  These  electronic 
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Figure  3:  Trading  Partner  to  VAN  Network  Connections 

mailboxes  work  just  like  “real”  mailboxes  in  that  mail  may  be  placed  in  them  at  any 
time.  The  mail  will  then  stay  in  the  mailbox  until  someone  is  ready  to  retrieve  it. 

There  are  a  number  of  VAN  service  providers  that  offer  VAN  mailboxes.  It  is 
important  that  all  of  the  trading  partners  that  wish  to  exchange  EDI  transactions 
use  the  same  VAN  provider  or  use  VAN  providers  that  offer  a  gateway  to  other  VANs 
so  that  mail  and  EDI  transactions  can  be  forwarded  to  the  proper  destination. 

Figure  3  shows  the  network  connections  between  two  trading  partners  and  a  VAN 
provider.  In  this  scenario,  trading  partner  A  will  create  an  EDI  transaction  file  (such 
as  an  invoice)  and  use  the  modem  to  upload  this  file  to  the  VAN.  The  file  is  placed 
in  a  VAN  mailbox  assigned  to  trading  partner  B.  The  file  will  remain  in  the  VAN 
mailbox  until  it  is  retrieved.  Some  time  later,  trading  partner  B  will  use  their  modem 
to  download  the  EDI  invoice  transaction  from  the  VAN  mailbox  and  then  process  the 
EDI  transaction. 

By  using  a  VAN  mailbox,  trading  partner  A  can  upload  EDI  transactions  at  any 
time.  For  example,  they  may  gather  several  EDI  transactions  and  upload  them  at 
night  when  the  phone  rates  are  cheaper.  Similarly,  trading  partner  B  can  download 
one  or  more  EDI  transactions  when  it  is  convenient  or  least  costly. 
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5 


EDI  Standards 


EDI  standards  provide  a  common  language  that  allows  trading  partners  to  com¬ 
municate  electronically.  In  the  past,  many  companies  used  proprietary  formats  to 
communicate  with  each  of  their  trading  partners.  Since  a  company  often  has  more 
than  one  trading  partner,  many  different  proprietary  formats  had  to  be  maintained 
by  a  single  trading  company.  The  result  was  high  maintenance  cost. 

An  earlier  alternative  to  this  problem  was  to  develop  industry-specific  standards. 
However,  this  was  still  not  a  good  solution  as  many  companies  trade  with  compa¬ 
nies  outside  of  their  own  industry.  Therefore,  they  still  had  to  use  several  different 
standards.  There  was  a  need  for  national  standards. 

In  1979  the  American  National  Standards  Institute  (ANSI)  began  developing  the 
ASC  X12  standards  for  EDI.  At  the  same  time,  with  the  emergence  of  many  multi¬ 
national  companies  and  with  the  growing  global  economy,  there  was  a  pressing  need 
for  international  standards.  In  1985  the  United  Nations  began  developing  EDIFACT. 
In  the  next  several  subsections  we  shall  describe  these  standards. 


5.1  ANSI  Accredited  Standards  Committee  -  X12 

5.1.1  History  of  ANSI  ASC  X12 

In  1979  the  American  National  Standards  Institute  chartered  the  Accredited  Stan¬ 
dards  Committee  with  the  task  of  developing  EDI  standards.  The  objective  was  to 
merge  the  industry-specific  standards  (e.g.,  transportation  industry  standards  pub¬ 
lished  by  the  Transportation  Data  Coordinating  Committee  (TDCC)  or  auto  industry 
standards  published  by  the  Automobile  Industry  Action  Group  (AIAG))  and  also  to 
develop  new  general  purpose  standards  [Can93].  The  first  version  of  the  X12  stan¬ 
dards,  developed  by  ASC,  were  approved  by  ANSI  in  1983  [Dat93]. 

5.1.2  ANSI  ASC  X12  Functions 

The  Accredited  Standards  Committee  X12  meets  three  times  a  year  to  discuss  new 
proposals  for  EDI  standards.  New  transaction  sets  can  be  proposed  and  existing 
standards  can  be  augmented  with  new  data  elements.  The  implementation  of  a  new 
transaction  set  or  the  changes  to  an  existing  set  follow  this  path  [Cro95]: 

1.  An  individual,  an  organization  or  some  recognized  group  (such  as  the  AIAG) 
drafts  a  memo  of  the  proposed  changes  or  additions  that  will  affect  an  X12 
standard.  This  memo,  called  a  Data  Maintenance  Request^  presents  the  justifi¬ 
cation  for  the  change  and  is  sent  directly  to  the  ASC  for  consideration  in  the 
next  meeting. 

2.  The  ASC  will  hand  over  the  request  to  a  specific  subgroup  within  the  ASC  for 
closer  review. 
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Transaction  Begin 

Data  Segment  1  Begin 
Data  Element  A 
Data  Element  B 
Data  Element  C 
Data  Segment  1  End 
Data  Segment  2  Begin 
Data  Element  D 
Data  Element  E 
Data  Segment  2  End 
Transaction  End 


Figure  4:  Building  Blocks  of  an  ANSI  ASC  X12  Standard 

3.  At  the  next  meeting,  all  of  the  proposed  changes  received  since  the  last  meeting 
are  discussed.  All  members  debate  the  pros  and  cons  of  adopting  the  change  or 
addition.  A  final  vote  is  taken  on  the  matter. 

4.  If  the  change  is  accepted,  it  will  be  published  by  the  ASC.  If  the  change  is 
not  accepted,  then  the  sponsoring  group  can  make  revisions  and  resubmit  the 
proposal  for  consideration  at  the  next  meeting. 

5.1.3  X12  Standards  Components 

The  Data  element  is  the  basic  building  block  of  the  ANSI  ASC  X12  standards.  Data 
elements  are  combined  to  make  a  data  segment,  and  data  segments  are  combined  to 
form  an  EDI  transaction  as  seen  in  Figure  4. 

For  a  transaction  to  be  acceptable  by  the  EDI  standards,  all  the  data  elements 
must  be  defined  within  the  X12  standards.  To  create  and  use  new  data  elements 
which  are  not  already  defined  in  the  standards,  a  formal  request  must  be  made  to  the 
ASC  X12  committee. 

It  is  possible  that,  due  to  line  noise  or  interference,  an  EDI  transaction  could 
become  corrupted  during  transmission.  In  order  to  guard  against  lost  data  and  to 
improve  failure  control  under  these  circumstances,  X12  transactions  are  augmented 
with  three  levels  of  control  segments,  also  called  envelopes.  The  three  levels  of  control 
segments  are: 

Transaction  Set  Wraps  around  an  individual  EDI  transaction  and  contains  infor¬ 
mation  about  the  type  of  transaction  (e.g.  Invoice). 

Functional  Group  Wraps  around  one  or  more  transaction  sets  of  the  same  type. 
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Interchange  Header 


Functional  Group  Header 

Transaction  Set  Header 

Transaction  (Invoice  1) 
Transaction  Set  Trailer 
Transaction  Set  Header 

Treoisaction  (Invoice  2) 
Transaction  Set  Trailer 
Functional  Group  Trailer 

Functional  Group  Header 

Transaction  Set  Header 

Transaction  (Payment  Notice) 
Transaction  Set  Trailer 
Functional  Group  Trailer 

Interchange  Trailer 


Examples  of  transactions  such  as  Invoice  and  Payment  Notice  are  given  in  parentheses. 
Figure  5;  Control  Segments  used  in  the  ANSI  ASC  X12  Standard 

Interchange  Wraps  around  the  entire  EDI  message  (around  all  functional  groups) 
and  includes  all  of  the  information  required  to  deliver  the  EDI  transaction  to 
its  destination. 

An  outline  of  the  control  segments  used  in  the  ANSI  ASC  X12  standard  can  be 
seen  in  Figure  5.  A  list  of  transaction  sets  contained  in  the  ANSI  ASC  X12  standard 
is  given  in  Appendix  I  starting  on  page  34. 

5.2  International  Standards  -  EDIFACT 
5.2.1  History  of  EDIFACT 

As  the  ANSI  ASC  EDI  standards  were  beginning  to  win  mass  acceptance  in  North 
America  in  the  mid  1980s,  individual  countries  began  to  work  together  under  the 
United  Nations  (UN)  to  form  international  standards  for  electronic  messaging. 

As  recently  as  1985,  the  United  Nations  Economic  Commission  for  Europe  (UN/ECE) 
approached  the  ANSI  ASC  X12  committee  with  the  intent  to  work  together  to  form 
global  EDI  standards.  In  1986,  the  Electronic  Data  Interchange  for  Administration, 
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Commerce  and  Transport  (EDIFACT)  committee  was  formed  for  the  purposes  of 
carrying  out  this  mission  [Kim91]. 

By  1989,  member  nations  included  all  of  North  America  and  many  countries  in 
Europe,  South  America  and  the  Pacific  Rim.  Message  structures  covering  most  of 
the  major  business  functions  have  since  been  created  [Kim91]. 

5.2.2  EDIFACT  Functions 

The  EDIFACT  committees  meet  on  a  schedule  similar  to  their  ANSI  ASC  X12  coun¬ 
terparts  in  the  U.S.  With  member  countries  spanning  the  globe,  meetings  are  held  in 
alternating  locations  several  times  a  year.  The  content  of  the  meetings  is  again  simi¬ 
lar  to  that  of  the  ASC  X12  gatherings.  New  transactions  are  proposed  and  changes 
or  additions  to  existing  standards  are  debated. 

Since  the  standard  transactions  must  apply  to  diverse  industries  across  nations, 
the  procedures  for  proposing  an  addition  or  change  are  slightly  different  [Cro95]: 

1.  Within  a  given  country,  the  local  standards  bureau  (such  as  the  ANSI  ASC 
committee  in  the  U.S.)  first  approves  the  proposed  addition  or  change  to  an 
EDIFACT  standard. 

2.  Once  approved  at  the  local  level,  the  request  is  submitted  to  the  UN/EDIFACT 
committee  for  consideration  at  the  following  meeting. 

3.  At  the  next  meeting,  all  of  the  proposed  changes  received  since  the  last  meeting 
are  discussed.  All  members  debate  the  pros  and  cons  of  adopting  the  change  or 
addition.  A  final  vote  is  taken  by  all  of  the  member  countries  on  the  matter. 

4.  If  the  change  is  accepted,  it  will  be  published  by  the  UN/EDIFACT  committee. 
If,  however,  any  country  does  not  agree  with  the  changes  or  additions,  the 
proposal  must  be  rewritten  and  debated  again  at  the  following  meeting. 

Because  of  the  lengthy  and  thorough  review  process  and  the  challenge  of  meeting 
the  needs  of  many  member  countries,  progress  on  the  EDIFACT  standards  is  generally 
a  very  slow  process. 

5.2.3  EDIFACT  Standards  Components 

The  EDIFACT  standards  appear  to  be  similar  in  form  to  the  ANSI  ASC  X12  trans¬ 
actions.  There  are,  however,  a  few  subtle  differences  in  terminology. 

As  with  X12,  the  basic  structure  of  an  EDIFACT  message  is  the  data  element. 
A  data  element  contains  a  single  data  value  such  as  a  phone  number  or  company 
name.  A  segment  is  a  logical  group  of  data  elements  such  as  a  “Bill  To”  address.  An 
EDIFACT  message  contains  a  group  of  segments  that  represent  a  business  document 
such  as  a  purchase  order  [TS92].  Note  that  while  EDIFACT  uses  the  term  message, 
X12  prefers  the  term  transaction. 
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Interchange  Header 


Functional  Group  Header 
Message  Header 

Segment  (DE,  DE,  DE,  DE) 

Segment  (DE,  DE,  DE,  DE) 

Message  Trailer 
Message  Header 

Segment  (DE,  DE,  DE,  DE) 

Segment  (DE,  DE,  DE,  DE) 

Segment  (DE,  DE,  DE,  DE) 

Segment  (DE,  DE,  DE,  DE) 

Message  Trailer 
Functional  Group  Trailer 

Functional  Group  Header 
Message  Header 

Segment  (DE,  DE,  DE,  DE) 

Segment  (DE,  DE,  DE,  DE) 

Message  Trailer 
Functional  Group  Trailer 

Interchange  Trailer 


Where  DE  =  Data  Element 

Figure  6:  Building  Blocks  of  an  EDIFACT  Standard 

An  interchange  is  a  group  of  one  or  more  messages  that  is  sent  from  one  trading 
partner  to  another.  Each  message  can  be  of  a  different  type  within  the  interchange. 
For  example,  an  interchange  might  include  a  purchase  order  and  a  payment  receipt. 
A  functional  group  is  an  interchange  where  all  of  the  messages  are  the  of  the  same 
type  [TS92]. 

Each  of  these  structures  has  a  beginning  code  and  ending  code  associated  with 
them.  These  codes  are  called  Headers  and  Trailers  respectively.  An  outline  of  an 
EDIFACT  structure  can  be  seen  in  Figure  6. 

A  listing  of  EDIFACT  standards  based  on  version  D93.A  are  given  in  Appendix 
II  starting  on  page  41. 
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5.3  Merging  Standards 

It  is  clear  that  although  the  U.S.  was  the  first  country  to  make  widespread  use  of 
EDI  and  EDI  standards,  the  needs  of  the  global  economy  have  taken  precedence.  For 
EDI  standards,  this  manifests  itself  in  the  need  to  merge  the  ANSI  ASC  X12  and 
EDIFACT  standards  into  a  single  cohesive  standard. 

The  existing  transactions  in  EDIFACT  include  all  of  the  functionality  of  the  cor¬ 
responding  X12  transaction  and  are,  in  most  cases,  a  generalization  of  the  X12  trans¬ 
action  sets.  Because  of  this,  the  merging  of  the  two  standards  has  become  more  of  a 
transition  from  X12  to  EDIFACT.  This  is  accomplished  by  broadening  the  EDIFACT 
standards  to  retain  the  same  functionality  in  the  X12  standards. 

There  is  a  reluctance  to  change  over  to  the  EDIFACT  standard  due  to  the  existing 
investment  made  by  U.S.  industries  in  ASC  X12  compliant  software  and  systems. 
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6  Examples  of  EDI  Transactions 

In  previous  sections,  descriptions,  benefits  and  definitions  of  EDI  implementations 
have  been  given.  In  this  section,  a  detailed  example  of  a  simple  EDI  transaction 
session  will  be  given.  Another  example  of  a  longer  term  exchange  of  EDI  transactions 
will  also  be  shown. 

6.1  Example  1  -  Purchase  Order 

For  this  example,  assume  that  two  trading  partners  wish  to  use  EDI  for  the  pur¬ 
poses  of  sending  and  receiving  purchase  orders.  The  first  company,  Hats  R  Us  is  a. 
manufacturer  of  hats  while  the  second  Fabric  City  is  a  supplier  of  fabric.  The  hat 
manufacturer  maintains  a  manufacturing  database  on  a  minicomputer  that  includes 
a  Purchasing  system  capable  of  creating  and  storing  purchase  orders.  The  fabric 
supplier  has  a  database  for  maintaining  customer  orders  and  shipping  information 
on  a  personal  computer  local  area  network.  Both  partners  have  agreements  with  the 
same  VAN  service  company  to  transmit  the  EDI  transactions.  Both  partners  have 
also  agreed  to  use  the  ANSI  ASC  X12  transaction  set. 

The  scenario  for  this  example  depicts  the  hat  manufacturer’s  purchase  order  being 
sent  to  the  fabric  supplier.  Figure  7  shows  the  basic  flow  of  information  between  the 
two  trading  partners.  The  steps  required  for  this  transaction  are  as  follows: 

1.  A  purchasing  agent  from  the  hat  manufacturer  creates  a  purchase  order  for 
some  fabric  indicating  Fabric  City  as  the  intended  supplier.  A  sample  PO  data 
entry  screen  can  be  seen  in  Figure  8. 

2.  At  a  predetermined  time  each  day,  a  mapping  routine  written  by  Hats  R  Us’ 
MIS  staff  extracts  new  purchase  orders  from  the  purchasing  database  into  a  flat 
file.  The  flat  file  corresponding  to  the  PO  can  be  seen  in  Figure  9. 

3.  The  EDI  Translation  software,  purchased  from  a  commercial  software  vendor, 
reads  the  flat  file  and  reformats  the  file  into  an  EDI  transaction.  This  is  accom¬ 
plished  by  inserting  the  appropriate  X12  standard  codes  for  the  850  transaction 
set  (Purchase  Order)  in  the  transaction  file. 

Additional  information  is  added  to  the  EDI  transaction  from  information  about 
specific  trading  partners  held  in  a  small  database  maintained  by  the  EDI  trans¬ 
lation  software.  The  final  EDI  transaction  file  can  be  seen  in  figure  10. 

4.  At  this  point,  the  EDI  transaction  is  packed  and  ready  to  be  delivered  by  dialing 
a  modem  to  the  VAN  and  uploading  the  EDI  transaction  file  to  an  electronic 
mailbox  owned  by  Fabric  City. 

Once  the  PO  has  been  successfully  uploaded  to  the  VAN,  it  will  remain  in  the 
mailbox  until  it  is  downloaded  as  a  customer  order  by  Fabric  City. 
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Hats  R  Us  Fabric  City 


Figure  7:  EDI  Information  Flow  Between  Hats  R  Us  and  Fabric  City 
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I  Hats  R  Us  Purchase  Order  Date:  July  1,  1994 

I  123  Bowler  Lane  PO  Num:  912-111 

I  Fedora,  TN  01234  + - 


I  I  Sub-Total:  $3,000 
I  Vendor:  Fabric  City  I  Shipping:  100 
I  456  Paisley  Park  Drive  I  - 


1 

Plaid,  NB  98765 

1  Total: 

$3,100 

+ - 

1  Item 

Part  Description 

Qty.  Cost 

Total 

I 

1  1 

534-32  Terrycloth 

1000  yd.  $1.00 

$1,000.00 

1  2 

+ - 

524-31  Linencloth 

1000  yd.  $2.00 

$2,000.00 

Figure  8:  Purchase  Order  From  Hats  R  Us 

5.  Fabric  City  has  a  program  that  automatically  polls  the  VAN  mailbox  for  new 
messages.  When  a  new  message  is  found,  it  is  downloaded  and  saved  as  an 
incoming  EDI  transaction. 

The  EDI  transaction  file  looks  identical  to  the  file  uploaded  by  Hats  R  Us. 

6.  The  EDI  translation  software  now  goes  to  work  to  unpack  the  PO  transaction 
and  to  save  the  relevant  parts  into  a  flat  ASCII  file. 

Again,  this  flat  ASCII  file  looks  identical  to  the  file  produced  by  Hats  R  Us. 

7.  Since  the  incoming  file  is  a  purchase  order.  Fabric  City  is  required  to  treat  this 
file  as  a  customer  order.  The  database  mapping  routine  maps  the  incoming 
purchase  order  into  the  customer  order  portion  of  the  database. 

The  final  customer  order  can  be  seen  in  the  Fabric  City  database  in  figure  11. 
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ponumber:  912-111 

date:  July  1,  1994 

fromnajne:  Hats  R  Us  Purchase  Order 

fromaddressl :  123  Bowler  Lane 

fromaddress2 :  Fedora,  TN  01234 

tovendornajne :  Fabric  City 

tovendoraddressl :  456  Paisley  Park  Drive 

tovendoraddress2 :  Plaid,  NB  98765 

sub-total:  3000 

shipping :  100 

totalPQ:  3100 

item:  1 

part :  534-32 

description:  Terrycloth 

quantity:  1000  yd. 

cost:  1 

itemtotal:  1000 
item:  2 
part :  524-31 
description :  Linencloth 
quantity:  1000  yd. 
cost:  2 

Figure  9:  Flat  ASCII  File  Representation  of  the  Hats  R  Us  Purchase  Order 
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ISA*00*000000000000000*01*password*01*12345678*dunl234* 
*890714*2210*U*0020*00000000008**0*P* ; 
GS*IN*12345678*940701*900959*2212*0000001*X*002040 
31*850*00001 
BIG*940701*912-111 
Nl*BT*Hats  R  Us 
N2*123  Bowler  Lcine 
N3*Fedora,  TN  01234 
Nl*SE*Fabric  City 
N2*456  Paisley  Park  Drive 
N3*Plaid,  NB  98765 
IT1*1000*YD*1 . 00*VC*534-32 
IT1*1000*YD*2 . 00*VC*524-31 
TDS*3100 
CTT*2*20 
SE*21*00000001 
GE*1*00000001 
IEA*1*00000000008 


The  line  starting  with  ISA  is  the  Interchange  Control  Header.  The  line  starting 
with  GS*IN  is  the  Functional  Group  Header.  The  line  starting  with  ST*850  is  the 
Transaction  Set  Header  indicating  set  number  850  is  being  used. 

Figure  10:  EDI  Transaction  (set  850)  for  the  Hats  R  Us  Purchase  Order 
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I  Customer  Order  Screen  I 


Customer:  Hats  R  Us  Date:  July  1,  1994 

123  Bowler  Lane 
Fedora,  TN  01234 

Sub-Total:  $3,000  Order  Number:  1001 


Shipping : 

100 

Taken  By : 

via  EDI 

Total : 

$3,100 

Item  Part 

Description 

qty. 

Cost 

Total 

1  534-32 

2  524-31 

Terrycloth 

Linencloth 

1000  yd 
1000  yd. 

.  $1.00 
.  $2.00 

$1,000.00 

$2,000.00 

Figure  11:  The  Hats  R  Us  Customer  Order  in  Fabric  City’s  Database 
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6.2  Example  2  -  Government  Bidding 

This  example  of  a  series  of  EDI  transactions  will  demonstrate  the  full  lifecycle  for  a 
U.S.  government  agency  bid  for  products.  In  the  previous  example,  the  details  for 
the  mapping,  translation  and  transmission  of  EDI  messages  were  described.  In  this 
example,  several  rounds  of  EDI  messages  are  described  but  the  message  details  have 
been  omitted  for  brevity.  A  more  general  example  of  governmental  EDI  can  be  found 
in  section  3.4  of  [imp94]. 

When  a  government  agency  wishes  to  purchase  a  large  quantity  of  materials  it 
usually  must  solicit  bids  from  several  potential  suppliers  and  then  choose  one  based 
on  some  criteria.  From  the  EDI  perspective,  this  process  can  involve  exchanging  seven 
or  more  different  message  types. 

1.  The  first  step  is  for  the  government  agency  to  package  a  Request  for  Quote 
(RFQ)  and  send  this  RFQ  (transaction  set  840)  out  to  a  number  of  suppliers. 

The  RFQ  will  have  a  bid  due  date  indicating  when  the  quotes  (bids)  must 
be  submitted  by,  shipping  instructions  for  the  materials  to  be  provided  and  a 
number  of  line  items  with  standardized  part  numbers. 

2.  A  supplier  that  receives  an  RFQ  may  reply  with  a  request  for  technical  infor¬ 
mation  about  one  or  more  of  the  line  items  on  the  RFQ. 

3.  The  government  agency  will  then  furnish  additional  technical  information  to 
the  supplier  via  transaction  set  841. 

The  previous  steps  can  be  repeated  several  times  if  more  technical  information 
is  required. 

4.  Each  supplier  will  then  prepare  a  bid  based  on  some  or  all  of  the  line  items  of 
the  RFQ.  This  bid  or  “Response  to  RFQ”  (transaction  set  843)  is  sent  to  the 
government  agency.  It  is  possible  to  provide  bids  for  only  some  of  the  items  on 
the  RFQ.  Other  variances  such  as  delivery  date  and  cost  may  also  be  noted  on 
the  bid. 

5.  After  the  bidding  due  date  has  passed,  the  agency  will  then  make  a  decision 
to  award  the  contract  to  one  or  more  of  the  suppliers.  It  is  not  uncommon  to 
award  parts  of  the  contract  to  different  suppliers. 

The  suppliers  that  win  awards  will  then  be  sent  contact  award  notices  (transac¬ 
tion  set  836)  followed  by  purchase  orders  (transaction  set  850  as  in  the  previous 
example). 

6.  Upon  receipt  of  the  purchase  orders,  the  suppliers  will  immediately  send  back 
a  purchase  order  acknowledgement  (transaction  set  855)  to  the  government 
agency. 
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7.  When  the  supplier  is  ready  to  ship  the  materials  to  the  agency,  they  may  send 
an  advanced  shipping  notice  (transaction  set  856)  which  includes  a  manifest  of 
the  items  on  their  way  to  the  agency. 

8.  After  the  delivery,  each  supplier  will  then  follow  up  with  an  invoice  (transaction 
set  810)  to  facilitate  payment  for  the  delivered  materials. 

In  terms  of  cost  savings  over  a  paper  based  scenario,  note  that  each  additional 
potential  supplier  in  the  above  exchange  equates  to  the  following  additional  docu¬ 
mentation: 

•  Initial  RFQ  to  be  sent  out 

•  Technical  specifications  and  other  information  to  be  sent  out 

•  Bid  to  be  received 

This  extensive  exchange  of  messages  is  currently  carried  out  using  traditional 
paper  and  postal  service  methods.  Performing  the  above  scenario  using  EDI  transac¬ 
tions  represents  a  significant  savings  in  the  total  lifecycle  time  as  well  as  in  the  cost 
of  preparing,  sending  and  receiving  the  various  documents. 

The  previous  examples  serve  to  illustrate  both  the  complexity  of  the  implemen¬ 
tation  details  and  the  potential  cost  and  time  savings  that  are  indicative  of  EDI 
implement  at  ions . 


7  EDI  Challenges 

In  this  section,  some  of  the  many  challenges,  present  and  future,  for  developing  an 
effective  EDI  implementations  are  discussed. 

7.1  Compatibility 

Information  systems  that  use  EDI  may  be  incompatible  in  one  or  more  of  the  following 
ways: 

1.  The  databases  or  information  systems  used  by  each  of  the  trading  partners 
may  differ  significantly.  For  example,  different  terminology  may  be  used  when 
describing  the  various  business  forms  and  practices.  The  physical  layout  of  data 
tables  and  data  files  may  also  differ. 

2.  EDI  translation  software  differs.  Different  implementations  of  the  same  EDI 
standard  by  different  software  vendors  can  lead  to  some  incompatibilities. 
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3.  Value  Added  Network  (VAN)  providers  differ.  If  trading  partners  subscribe  to 
two  different  VANs,  then  they  may  not  be  able  to  exchange  EDI  messages. 

One  of  the  promises  of  EDI  is  to  adapt  to  incompatibilities  in  basic  information 
systems  as  in  the  first  item  above.  Provided  a  common  EDI  standard  is  strictly 
adhered  to,  the  particular  vendors  of  EDI  translation  software  should  not  pose  a 
problem.  Certain  VAN  providers  can  also  supply  gateways  to  other  VAN  services 
which  can  alleviate  problems  as  noted  in  the  third  item  above. 

Using  identical  information  systems,  EDI  standards,  EDI  translation  software  and 
VAN  providers  for  all  trading  partners  poses  an  ideal  situation  which  is  encountered 
in  several  industries.  In  its  early  years,  EDI  was  first  implemented  by  large  manu¬ 
facturers  and  shipping  companies.  In  many  cases,  the  size  and  purchasing  power  of 
these  companies  allowed  them  to  dictate  specific  hardware  and  software  combinations 
to  their  trading  partners.  This  implementation  technique  alleviates  a  large  part  of 
the  implementation  problems  attributed  to  incompatible  systems. 

Although  this  method  works  for  large  companies  with  relatively  few  suppliers, 
current  trends  indicate  many  more  small  businesses  would  also  like  to  benefit  from 
EDI.  Small  businesses  may  be  less  likely  to  dictate  specific  software  and  hardware  sys¬ 
tems  to  trading  partners.  This  results  in  each  trading  partner  implementing  differing 
information  systems  that  may  lead  to  the  incompatibility  problems  discussed. 

Relationships  with  international  trading  partners  heighten  the  compatibility  re¬ 
quirements  as  international  EDI  standards  such  as  EDIFACT  must  be  followed.  As 
with  the  compatibility  issues  discussed  here,  the  compatibility  challenges  are  strictly 
technical  in  the  sense  that  firm  standards  followed  precisely  can  alleviate  many  of 
the  compatibility  issues.  Following  these  international  standards  will  allow  trading 
partners  from  around  the  world  to  do  business  using  EDI. 

7.2  U.S.  Government  Demands 

Several  governmental  initiatives  for  implementing  EDI  have  been  put  forth  recently. 
Military  procurement  offices  such  as  the  Defense  Logistics  Agency  (DLA)  and  the 
Defense  Personnel  Support  Center  (DPSC)  have  indicated  a  strong  desire  to  perform 
most  business  transactions  electronically.  For  large  companies  that  may  already  have 
other  EDI  systems  in  place,  working  with  the  government  can  be  treated  like  any 
other  business  relationship.  For  companies  without  EDI  experience  (especially  small 
businesses),  the  added  demands  of  the  governmental  EDI  pose  a  major  challenge. 

Fortunately,  the  U.S.  government  is  wilhng  to  provide  assistance  to  small  busi¬ 
nesses  that  are  interested  in  becoming  EDI  capable.  The  DoD  and  the  DLA  can 
provide  a  number  of  brochures  and  guides  to  implementing  “governmental  EDI”  for 
small  businesses  (See  for  example  [HH93]).  The  specific  contacts  for  this  information 
are  given  in  Appendix  III  starting  on  page  43. 
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7.3  Small  Business 


The  challenges  of  implementing  EDI  are  made  more  apparent  when  small  businesses 
are  considered.  A  typical  small  business  may  not  have  an  integrated  database  system 
in  place  that  works  with  purchasing,  billing  and  other  areas  of  the  company.  Of¬ 
ten,  these  functions  are  performed  on  personal  computer  spreadsheets  or  single  user 
databases.  Although  some  staff  may  be  familiar  with  personal  computers  and  some 
applications  such  as  word  processing  and  spreadsheets,  EDI  translation  packages  and 
VAN  communications  are  typically  more  complex  to  learn  and  to  administrate. 

Choosing  an  EDI  system  and  network  provider  is  also  more  difficult  due  to  the 
possible  lack  of  employees  that  can  be  dedicated  to  the  task.  Lastly,  the  up  front 
cost  of  EDI  may  also  pose  a  barrier  to  small  businesses.  Initial  start  up  costs  for 
EDI  may  be  difficult  to  justify  especially  when  the  payback  period  is  long.  Because  a 
small  business  may  not  generate  a  large  number  of  business  transactions,  the  payback 
period  may  be  considerably  longer. 

Small  businesses,  especially  newly  formed  small  businesses,  have  the  advantage 
of  business  flexibility.  Because  EDI  focuses  on,  and  changes  the  way  a  company 
does  business,  small  businesses  are  able  to  adapt  quickly  and  take  advantage  of  EDI 
benefits. 

7.4  Trading  Partner  Agreements 

Traditionally,  EDI  has  worked  best  when  trading  partners  extend  their  existing  busi¬ 
ness  relationships  to  include  transactions  made  via  EDI.  In  such  cases,  trading  partner 
agreements  (TPA)  are  created  and  adhered-to  by  both  parties.  A  typical  TPA  might 
include  the  following  information  [GT94]: 

•  A  list  of  business  transactions  to  be  exchanged 

•  Specific  EDI  standards  to  be  followed  (e.g.  EDIFACT  or  X12) 

•  Contingency  plans  and  liability  statements  in  the  event  of  transmission  or  EDI 
syntax  errors 

Since  these  relationships  tend  to  be  long  term,  TPAs  are  viable  tools  that  can 
help  to  ensure  the  success  of  an  EDI  project.  Typically  a  TPA  will  exist  for  each  pair 
of  trading  partners.  For  a  detailed  example  of  an  EDI  Trading  Partner  Agreement, 
please  refer  to  [Bak91]  Appendix  C. 

However,  under  the  more  general  umbrella  of  Electronic  Commerce  (EC),  business 
relationships  may  be  created  and  terminated  within  a  very  short  period  of  time.  It 
may  be  necessary  to  exchange  EDI  transactions  between  trading  partners  who  have 
never  been  in  contact  before  (and,  hence  no  TPA  would  exist). 

An  example  of  such  a  relationship  would  be  a  customer  who  walks  into  a  sporting 
goods  store  to  purchase  a  pair  of  sneakers.  The  “business  relationship”  lasts  no  more 
than  an  hour  and  the  transactions  involve  a  very  brief  exchange  of  currency. 
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In  order  to  accommodate  such  relationships  in  the  EDI  world,  more  general  TPAs 
that  are  applicable  to  a  wide  range  of  business  relationships  need  to  be  crafted. 
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8  Appendix  I  -  ANSI  ASC  X12  Transaction  Sets 

The  ANSI  ASC  X12  standard  has  over  ninety  official  transaction  sets  and  many  more 
draft  specifications.  Some  of  theses  transaction  sets  are  described  in  the  following 
tables  in  order  of  transaction  set  number.  These  tables  contain  transactions  that  are 
part  of  the  ANSI  ASC  X12  version  3041  standard. 

The  middle  column  in  each  table  has  the  following  codes: 


TBD  To  Be  Deleted  as  of  June,  1994 

Ballot  Currently  being  voted  on  for  addition  to  X12  by  the  ASC  as  of  June,  1994 
Devel.  Under  Development  as  of  June,  1994  but  has  not  reached  the  voting  stage 
blank  Currently  in  use 

The  tables  are  broken  down  by  related  areas  for  the  transaction  sets.  New  trans¬ 
actions  are  being  developed  at  a  steady  pace  so  the  contents  of  this  table  is  subject 
to  change. 


Air  Shipmpnt  Transactions  _ _ _ 

Set  Number 

Code 

Name  and  Use 

101 

TBD 

FhEht  Confirmation 

104 

Air  Shipment  Information 

105 

TBD 

Container/ Equipment  Transfer  (Air) 

107 

TBD 

Shipment  Information  for  Export  Declaration  (Air) 

108 

TBD 

Shipment  Information  for  Import  (Air) 

109 

TBD 

Shipment  Information  for  Pickup/Delivery  Order 

110 

Air  Freight  Details  and  Invoice 

111 

TBD 

Freight  Details  and  Invoice  Summary  (Air) 

113 

TBD 

Inquiry  (Air) 

115 

TBD 

Status  Detadls  Reply  (Air) 

116 

TBD 

Repetitive  Pattern  Maintenance 

1  Ground  Shipment  Transactions  _ _ _ _ _ 

Set  Number 

Code 

Name  and  Use 

120 

Vehicle  Shipping  Order 

121 

Vehicle  Service 

125 

Multilevel  Railcar  Load  Details 

126 

Vehicle  Apphcation  Advice 

127 

Vehicle  Baying  Order 

128 

De2der  Information 

129 

Vehicle  Carrier  Rate  Update 

1  Student  Information  Transactions  _ _ _ _ _ 

Set  Number 

Code 

Name  and  Use 

130 

Student  Educational  Record  (Transcript) 

131 

Student  Educational  Record  (Transcript)  Acknowledgment 

135 

Student  Loan  Application 

139 

Student  Loan  Guarantee  Result 
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. . . . . . 1 

Set  Number 

Code 

Name  and  Use 

140 

Product  Registration 

141 

Product  Service  Claim  Response 

142 

Product  Service  Claim 

143 

Product  Service  Notification 

144 

Student  Loan  Transfer  and  Status  Verification 

146 

Request  for  Student  Educational  Record  (Transcript) 

147 

Response  to  Request  for  Student  Educational  Record  (Transcript) 

148 

Report  of  Injury  or  Din  ess 

Tax  Rate  Notification 

151 

Electronic  FiUng  of  Tax  Return  Data  Acknowledgment 

152 

Statistical  Government  Information 

154 

Uniform  Commercial  Code  FiUng 

161 

Train  Sheet 

170 

Revenue  Receipts  Statement 

175 

Court  Notice 

176 

Bankruptcy  Proof  of  Claiim 

180 

Return  Merchandise  Authorization  and  Notification 

185 

BaUot 

Royalty  Regulatory  Reports 

186 

Laboratory  Reporting 

190 

Student  Enrollment  Verification 

191 

Student  Loan  Preclaims 

195 

Ballot 

FCC  License  AppUcation 

196 

Contractor  Cost  Data  Reporting 

200 

Ballot 

Mortgage  Credit  Report 

201 

BaUot 

Residential  Loan  AppUcation 

203 

BciUot 

Secondary  Mortgage  Market  Investor  Report 

204 

Motor  Carrier  Shipment  Information 

210 

Motor  Carrier  Freight  Details  and  Invoice 

213 

Motor  Carrier  Shipment  Status  Inquiry 

214 

Transportation  Ccirrier  Shipment  Status  Message 

217 

Motor  Carrier  Loading  cuid  Route  Guide 

218 

Motor  Carrier  Tariff  Information 

250 

Purchase  Order  Shipment  Management  Document 

251 

Pricing  Support 

257 

BaUot 

Health  Care  EUgibiUty /Benefit  Inquiry  Immediate  Response 

258 

BaUot 

Health  Care  EUgibiUty /Benefit  Information  Immediate  Response 

260 

AppUcation  for  Mortgage  Insurance  Benefits 

263 

Residential  Mortgage  Insurance  AppUcation  Response 

264 

Mortgage  Loan  Default  Status 

265 

Real  Estate  Title  Insurance  Services  Order 

266 

BaUot 

Mortgage  Record  Exchange 

Healthcare  Transactions  | 

Set  Number 

Code 

Name  and  Use 

270 

Health  Care  EUgibiUty/Benefit  Inquiry 

271 

Health  Care  EUgibiUty/Benefit  Information 

272 

Property  and  Casualty  Loss  Notification 

276 

Heedth  Care  Claim  Status  Request 

277 

Health  Care  Claim  Status  Notification 

278 

BaUot 

Health  Care  Service  Review  Information 

279 

BcJlot 

Hecdth  Care  Service  Review  Request 

290 

Cooperative  Advertising  Agreements 
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Ocean  Shipment  Transactions 

Set  Number 

Code 

Name  and  Use 

300 

Reservation  (Booking  Request)  (Ocean) 

301 

Confirmation  (Ocecin) 

302 

TBD 

Container /Specialized  Equipment  Pick-up  Order 

303 

Booking  Cancellation  (Ocean) 

304 

Shipping  Instructions  (Ocean) 

305 

TBD 

Container/ Equipment  Transfer  (Ocean) 

306 

Dock  Receipt 

307 

TBD 

Shipment  Information  for  Export  Declaration  (Ocean) 

309 

U.S.  Customs  M2Lnifest 

310 

Freight  Receipt  and  Invoice  (Ocean) 

311 

Cmadian  Customs  Information 

312 

Arrival  Notice  (Ocean) 

313 

Shipment  Status  Inquiry  (Ocean) 

314 

TBD 

Shipment  Identities  and  Status  Reply  (Ocean) 

315 

Status  Details  (Ocean) 

316 

TBD 

Repetitive  Pattern  Maintenance  (Ocean) 

317 

Delivery /Pickup  Order 

319 

Terminal  Information 

321 

Demurrage  Guarantee  (Ocean) 

322 

Terminal  Operations  Activity  (Ocean) 

323 

Vessel  Schedule  and  Itinerary  (Ocean) 

324 

Vessel  Stow  Plan  (Ocean) 

325 

Consolidation  of  Goods  In  Container 

326 

Consignment  Summary  List 

350 

U.S.  Customs  Release  Information 

352 

U.S.  Customs  Carrier  General  Order  Status 

353 

U.S.  Customs  Events  Advisory  Detmls 

354 

U.S.  Customs  Automated  Manifest  Archive  Status 

355 

U.S.  Customs  Manifest  Acceptance/Rejection 

356 

U.S.  Customs  Permit  To  Transfer  Request 

357 

Ballot 

U.S.  Customs  In-Bond  Information 

358 

Ballot 

U.S.  Customs  Consist  Information 

360 

TBD 

Tariff  Information  (Ocean) 

361 

Carrier  Interchange  Agreement  (Ocean) 

362 

Cargo  InsuTcince  Advice  of  Shipment 

36 


Rail  Shipment  Transactions  I 

Set  Number 

Code 

Name  and  Use 

402 

Ballot 

Waybill  or  Historical  Rate  Request 

404 

Rail  Carrier  Shipment  Information 

410 

Rail  Ccu-rier  Freight  Details  and  Invoice 

411 

Freight  Details  and  Invoice  Summary 

414 

Rail  Car  hire  Settlements 

417 

Rail  Carrier  Waybill  Interchange 

418 

Rail  Advance  Interchcinge  Consist 

419 

Advance  Car  Disposition 

420 

Car  Hcindling  Information 

421 

Estimated  Time  of  Arrival  and  Ccir  Scheduling 

422 

Shipper’s  Car  Order 

423 

BcJlot 

Rail  Industrial  Switch  List 

424 

Switch  Bills 

425 

Rail  Waybill  Request 

426 

Rail  Revenue  Waybill 

to 

Ballot 

Rail  Waybill  Response 

429 

Railroad  Retirement  Activity 

431 

Railroad  Station  Mcister  File 

432 

Ballot 

Rail  Deprescription 

433 

Ballot 

Railroad  Reciprocal  Switch  File 

435 

Ballot 

Standcird  Transportation  Commodity  Code  Master 

440 

Shipment  Weights 

451 

Ballot 

Railro2id  Event  Report 

452 

Badlot 

Railroad  Problem  Log  Inquiry  or  Advice 

453 

Ballot 

Railroad  Service  Commitment  Advice 

455 

Ballot 

Railroad  Parameter  Trace  Registration 

456 

Ballot 

Railroad  Equipment  Inquiry  or  Advice 

460 

Rate  Format  Docket  Data 

461 

Rate  Format  Level  Data 

462 

Rate  Format  Sub-Level  Data 

463 

Ballot 

Rate  Rail  Reply 

464 

Rate  Set  Docket  Data 

465 

Rate  Set  Sub-Level  Data 

466 

Rate  Request 

467 

Scale  Rate  Docket  Transmittal 

468 

Rate  Docket  Journal  Log 

469 

Rate  Distribution  Set 

475 

Rail  Route  File  Maintenance 

480 

Docket/Cluster  Terminator 

485 

Ratemaking  Action 

486 

Ballot 

Rate  Docket  Expiration 

490 

Rate  Group  Definition 

491 

Rate  Increase/ Decrease  Transmittal 

492 

Miscellaneous  Rates 

493 

Devel. 

Rate  Docket  Data,  Part  1 

494 

Scale  Rate  Table 

499 

Application  Acceptance  Rejection  Advice 
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■  1 

Set  Number 

Code 

Name  and  Use 

511 

Requisition 

517 

Material  Obligation  Validation 

527 

Materiad  Due- In  and  Receipt 

536 

Logistics  Reassignment 

561 

Contract  Abstract 

567 

Contract  Completion  Status 

568 

Contract  Payment  Management  Report 

601 

Shipper’s  Export  Decl£iration 

602 

Transportation  Services  Tender 

622 

Intermodal  Ramp  Activity 

715 

Ballot 

Group  Loading  Plan 

_ 

Set  Number 

Code 

Name  and  Use 

805 

Contract  Pricing  Proposal 

806 

Project  Schedule  Reporting 

810 

Invoice 

811 

Consolidated  Service  Invoice /Statement 

812 

Credit/Debit  Adjustment 

813 

Electronic  Filing  of  Tax  Return  Data 

815 

Cryptographic  Service  Message 

816 

Organizational  Relationships 

818 

Commission  Sales  Report 

819 

Operating  Expense  Statement 

Set  Number 

Code 

Name  and  Use 

820 

Payment  Order /Remittance  Advice 

821 

Financial  Information  Reporting 

822 

Customer  Account  Analysis 

823 

Lockbox 

824 

Application  Advice 

826 

Tax  Information  Reporting 

827 

Financial  Return  Notice 

828 

Debit  Authorization 

829 

Payment  Cancellation  Request 

830 

Planning  Schedule  with  Release  Capability 

831 

Application  Control  Totcils 

832 

Price/Sales  Catalog 

833 

Residential  Mortgage  Credit  Report  Order 

834 

Benefit  Enrollment  and  Maintenance 

835 

Health  Care  Claim  Payment /Advice 

836 

Contract  Award 

837 

Heeiith  Csue  Cl£Lim 

838 

Trading  Partner  Profile 

839 

Project  Cost  Reporting 

840 

Request  for  Quotation 

841 

Specifications/Technicsd  Information 

842 

Nonconformance  Report 

843 

Response  to  Request  for  Quotation 

844 

Product  Transfer  Account  Adjustment 

845 

Price  Authorization  Acknowledgment /Status 

846 

Inventory  Inquiry/ Advice 

847 

Material  Claim 

848 

Material  Safety  Data  Sheet 

849 

Response  to  Product  Transfer  Account  Adjustment 
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_ 1 

Set  Number 

Code 

Name  and  Use 

850 

Purchase  Order 

851 

Asset  Schedule 

852 

Product  Activity  Data 

853 

Routing  and  Carrier  Instruction 

854 

Shipment  Delivery  Discrepancy  Information 

855 

Purchase  Order  Acknowledgment 

856 

Ship  Notice/ Manifest 

857 

Shipment  cind  Billing  Notice 

858 

Shipment  Information 

859 

Freight  Invoice 

860 

Purchase  Order  Change  Request  and  Buyer  Initiated 

861 

Receiving  Advice/ Acceptance  Certificate 

862 

Shipping  Schedule 

863 

Report  of  Test  Results 

864 

Text  Message 

865 

Purchase  Order  Chcinge  Acknowledgment /Request  and  Seller  Initiated 

866 

Production  Sequence 

867 

Product  Transfer  and  Resale  Report 

868 

Electronic  Form  Structure 

869 

Order  Status  Inquiry 

870 

Order  Status  Report 

872 

Residenticii  Mortgage  Insurance  Application 

874 

TBD 

Purchase  Order  -  Multipoint 

875 

Grocery  Products  Purchase  Order 

876 

Grocery  Products  Purchase  Order  Change 

877 

TBD 

Purchcise  Order  Adjustment  (UCS) 

878 

Product  Authorization/ Deauthorization 

879 

Price  Change 

_ 1 

Set  Number 

Code 

Name  and  Use 

880 

Grocery  Products  Invoice 

881 

TBD 

Credit  Merao/Debit  Memo 

882 

Direct  Store  Delivery  Summaury  Information 

883 

Market  Development  Fimd  Allocation 

884 

Market  Development  Fund  Settlement 

885 

Ballot 

Store  Chcuacteristics 

886 

Ballot 

Customer  Call  Reporting 

888 

Item  Maintenance 

889 

Promotion  Announcement 

890 

TBD 

Payment  Adjustment  Advice  (UCS) 

891 

Ballot 

Deduction  Research  Report 

892 

TBD 

Promotion  Annoimcement  Confirmation 

893 

Item  Information  Request 

894 

Delivery /Return  Base  Record 

895 

Deli  very /Return  Acknowledgment  or  Adjustment 

896 

Product  Dimension  Maintenance 
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Management  Transactions  J 

Set  Number 

Code 

Name  and  Use 

905 

TBD 

Remittance  Advice  (UCS) 

920 

Loss  or  Damage  Claim  and  General  Commodities 

924 

Loss  or  Damage  Claim  and  Motor  Vehicle 

925 

Claim  Tracer 

926 

Claim  Status  Report  and  Tracer  Reply 

928 

Automotive  Inspection  Detail 

940 

Warehouse  Shipping  Order 

941 

TBD 

Wcirehouse  Inventory  Status  Report 

942 

TBD 

Warehouse  Activity  Report 

943 

Wcirehouse  Stock  Transfer  Shipment  Advice 

944 

Warehouse  Stock  Transfer  Receipt  Advice 

945 

Warehouse  Shipping  Advice 

946 

Delivery  Information  Message 

947 

Warehouse  Inventory  Adjustment  Advice 

980 

Frmctional  Group  Totals 

990 

Response  to  a  Load  Tender 

994 

Administrative  Message 

995 

TBD 

Advisory  Information 

996 

File  Transfer 

997 

Functioned  Acknowledgment 

998 

Set  Cancellation 

999 

Acceptmee/ Rejection  Advice 
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9  Appendix  II  -  EDIFACT  Transaction  Sets 

The  international  EDIFACT  standards  has  similar  but  not  identical  standards  sets 
when  compared  to  the  ASC  X12  transactions.  Some  of  the  EDIFACT  standards 
currently  in  use  in  version  D93.A  are  given  in  the  following  table: 
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Set  Id 

Name  and  Use 

BANSTA 

Banking  Status  Message 

BAPLIE 

Bayplan/Stowage  Plan  Occupied  and  Empty  Locations 

BAPLTE 

Bayplan/Stowage  Plan  Toted  Numbers  Message 

CONDPV 

Direct  Payment  Valuation  Message 

CONEST 

Establishment  of  Contract 

CONITT 

Invitation  to  Tender  Message 

CONPVA 

Payment  Valuation  Message 

CONQVA 

Quality  Validation  Message 

CONTEN 

Tender  Message 

CREADV 

Credit  Advice  Message 

CREEXT 

Extended  Credit  Advice  Message 

CUSCAR. 

Customs  Cargo  Report  Message 

CUSDEC 

Customs  Declaration  Message 

CUSREP 

Customs  Conveycuice  Report  Message 

CUSRES 

Customs  Response  Message 

DEBADV 

Debit  Advice  Message 

DELFOR 

Delivery  Schedule  Message 

DELJIT 

Just  In  Time  Message 

DESADV 

Despatch  Advice  Message 

DIRDEB 

Direct  Debit  Message 

DOCADV 

Document£u*y  Credit  Advice  Message 

DOCAPP 

Dociunentary  Credit  AppUcation  Message 

DOCINF 

Documentetry  Credit  Issuance  Information  Message 

IFCSUM 

Forwarding  amd  Consolidation  Summary  Message 

IFTCCA 

Forwarding  and  transport  shipment  charge  calculation  msg. 

IFTMAN 

Arrival  Notice  Message 

IFTMBC 

Booking  Confirmation  Message 

IFTMBF 

Firm  Booking  Message 

IFTMBP 

Provisional  Booking  Message 

IFTMCS 

Instruction  Contract  Status  Message 

IFTMIN 

Instruction  Message 

IFTRIN 

Forwarding  and  tramsport  rate  information  message 

IFTSAI 

Forwarding  and  transport  schedule  and  availability  information  message 

IFTSTA 

International  Multimodal  Status  Report  Message 

INVOIC 

Invoice  Message 

INVRPT 

Inventory  Report  Message 

ORDCHG 

Purchase  Order  Change  Request  Message 

ORDERS 

Purchase  Order  Message 

ORDRSP 

Purchase  Order  Response  Message 

PARTIN 

Party  Information  Message 

PAXLST 

Passenger  List  Message 

PAYDUC 

Payroll  Deductions  Advice  Message 

PAYEXT 

Extended  Payment  Order  Message 

PAYMUL 

xMultiple  Payment  Order  Message 

PAYORD 

Payment  Order  Message 

PRICAT 

Price/Sales  Catalogue  Message 

QALITY 

Quality  Data  Message 

QUOTES 

Quote  Message 

REMADV  1 

Remittmce  Advice  Message 

REQOTE 

Request  For  Quote  Message 

SANCRT 

Sanita^Y/phytos^ulitary  Certificate 

SLSRPT 

SaJ.es  Data  Report  Message 

STATAC 

Statement  Of  Account  Message 

SUPCOT 

Superannuation  Contributions  Advice  Message 

SUPMAN 

Superannuation  MaJntenance  Message 
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10  Appendix  III  -  EDI  Resources  Directory 

The  EDI  industry  is  filled  with  various  standards  bodies  and  agencies  that  can  offer 
assistance  to  companies  who  are  interested  in  using  EDI.  In  particular,  the  U.S. 
Department  of  Defense  (DoD)  and  the  Defense  Logistics  Agency  (DLA)  are  more 
than  willing  to  help  businesses  become  EDI  capable.  Some  of  the  major  contacts  for 
EDI  information  are  given  in  this  section. 

The  Universal  Resource  Locator  (URL)  convention  is  used  for  FTP  and  World 
Wide  Web  sites  on  the  Internet. 

•  ANSI  ASC  X12  standards  information 

ASC  X12  Secretariat 
Data  Interchange  Standards  Association 
1800  Diagonal  Road,  Suite  355 
Alexandria,  Virginia  22314-2852 
Phone:  (703)  548-7005 


•  EDIFACT  standards  information 
Gaile  Spadin 

Data  Interchange  Standards  Association 
1800  Diagonal  Road,  Suite  355 
Alexandria,  Virginia  22314-2852 
Phone:  (703)  548-7005 


•  Publishers  of  the  ANSI  ASC  X12  standards 

Data  Interchange  Standards  Association  (DISA) 


•  Information  on  using  EDI  with  the  DoD  and  DLA 
U.S.  Department  of  Defense  (DoD) 

Logistics  Management  Institute 
2000  Corporate  Ridge 
McLean,  Virginia  22102-7805 
E-mail:  library@lmi.org 

Defense  Information  Systems  Agency 
Center  for  Standards 
ATTN:  TBCB-EC/EDI 
10701  Parkridge  Boulevard 
Reston,  Virginia  22091-4398 
E-mail:  edi@jcdbs.itsi.disa.mil 
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URL:  ftp : //ftp . sterling . com/ edi/DoD-edi/ 


Electronic  Commerce  Coordinator 
Defense  Personnel  Support  Center  (DPSC) 

DPSC-HIE  2800  South  20th  Street 
Philadelphia,  Pennsylvania  19101-8419 
Phone:  (215)  737-2987 

Call  the  National  Technical  Information  Service  (NTIS)  for  a  catalog  of  EDI 
related  publications  available  from  the  DoD.  Phone:  (703)  487-4650. 

•  Information  on  Electronic  Commerce  (EC) 

National  Institute  of  Standards  and  Technology 
Gaithersburg,  Maryland  20899 


•  Information  on  Product  Data  Exchange 

Initiative  for  Product  Data  Exchange  Office 
National  Institute  of  Standards  and  Technology 
Building  245,  Room  B102 
Gaithersburg,  Maryland  20899 
Phone:  (301)  975-3986 
Fax:  (301)  926-8730 


•  On-Line  Papers  on  EDI 

URL:  ftp :  //ftp .  sterling .  com/ edi 

•  On-Line  Information  on  EDI  Standards 
URL:  http://www.premenos.com 
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11  Glossary 


ACH 

Automated  Clearing  House 

AlAG 

Automotive  Industry  Action  Group 

ANSI 

American  National  Standards  Institute 

ASC 

Accredited  Standards  Committee 

ASCII 

Americcin  Standard  Code  for  Information  Interchange 

BBS 

Bulletin  Board  Service 

CAD 

Computer  Aided  Design 

CAE  n 

Computer  Aided  Engineering 

CAM 

Computer  Aided  Manufacturing 

CIM 

Computer  Integrated  Manufacturing 

DISA 

Data  Interchange  Standards  Association 

DLA 

Defense  Logistics  Agency 

DoD 

Department  of  Defense 

DPSC 

Defense  Personnel  Support  Center 

EC 

Electronic  Commerce 

EDI 

Electronic  Data  Interchange 

EDIA 

Electronic  Data  Interchange  Association 

EDIFACT 

Electronic  Data  Interchange  for  Administration,  Commerce  and  Transport 

EFTA 

European  Free  Trade  Association 

EFT 

Electronic  Fimds  Transfer 

E-Mail 

Electronic  Mail 

ERS 

Evciluated  Receipt  Settlement 

FAR 

Federal  Acquisition  Regulation 

FIPS 

Federal  Information  Processing  Standards 

FMS 

Financial  Management  Service 

FRB 

Federal  Reserve  Bcuik 

IETF 

Internet  Engineering  Task  Force 

IGES 

Initial  Graphics  Exchange  Specification 

IOC 

Initial  Operational  Capability 

lOS 

Inter-Organizational  Information  Systems 

ISO 

International  Standards  Organization 

JIT 

Just  In  Time 

MIME 

Multipurpose  Internet  Mail  Extensions 

MTA 

Message  Transfer  Agent 

Nil 

National  Information  Infrastructure 

NIST 

National  Institute  of  Standards  and  Technology 

NTE 

Note  segment  of  an  EDI  message 

OLDB 

On  Line  DataBase 

PC 

Personal  Computer 

PDE 

Product  Data  Exchange 

PDES 

Product  Data  Exchange  using  STEP 

PO 

Purchase  Order 

RDA 

Remote  Database  Access 

RFC 

Request  For  Comment 

RFP 

Request  For  Proposal 

RFQ 

Request  For  Quotation 

SBA 

Small  Business  Administration 

SF 

Standard  Form 

SGML 

Standard  Generalized  Mank-up  Lcuiguage 

SNA 

Systems  Network  Architecture 

STEP 

Standard  for  The  Exchange  of  Product  Model  Data 
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TramsDortation  Data  Coordinating  Committee 

UNECE  Trade  Data  Elements  Directory 

Trade  Data  Interchange  Directory 

TEDIS 

Trade  Electronic  Data  Interchange  Systems 

TPA 

Trading  Partner  Agreement 

TQM 

Total  Ouahtv  Management 

TS 

Transaction  Set 

TSDS 

Transaction  Set  Development  System 

UN-EDIFACT 

International  EDI  standcirds  committee 

UN/ECE 

United  Nations  Economic  Commission  for  Europe 

VAN 

Value  Added  Network 

VAS 

Value  Added  Service 

X12 

ANSI  ASC  sub-committee  charged  with  defining  U.S.  EDI  standards. 
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1  Introduction 


Several  software  and  hardware  components  are  required  to  facilitate  Electronic  Data 
Interchange  (EDI)  of  standard  business  transactions.  EDI  Translation  Software  plays 
the  role  of  a  universal  interpreter  between  two  businesses  or  trading  partners  by 
ensuring  that  a  common  standard  is  followed  for  the  format  of  an  EDI  message.  By 
adhering  to  a  common  standard,  businesses  can  fully  realize  the  benefits  of  EDI. 

The  software  market  for  EDI  translators  is  small  in  comparison  to  other  packages 
such  as  word  processing  or  spreadsheets,  however,  it  is  often  more  difficult  to  compare 
translation  software  due  to  the  overall  complexity  and  large  feature  sets  of  the  pack¬ 
ages.  EDI  Translators  are  usually  integrated  with  existing  company  databases  rather 
than  used  in  isolation.  This  makes  comparisons  even  more  difficult  as  the  integration 
of  EDI  translators  becomes  a  major  issue. 

The  objectives  of  this  paper  are  to: 

1.  Give  a  brief  overview  of  EDI; 

2.  Describe  a  set  of  basic  features  that  all  EDI  translators  should  possess; 

3.  Describe  a  set  of  additional  features  that  are  desirable  in  an  EDI  translator; 

4.  Introduce  a  collection  of  technical  and  nontechnical  criteria  for  evaluating  EDI 
translators; 

5.  Develop  a  structured  tool  for  evaluating  EDI  translation  software;  and 

0.  Present  an  evaluation  procedure  iov  EDI  translation  software  that  uses  the  struc¬ 
tured  evaluation  tool. 

2  Overview  of  EDI 

^  All  over  the  world,  companies  conduct  business  by  exchanging  documents  such 
as  orders,  contracts,  catalogs  and  payments.  With  the  advent  of  computers  and 
information  systems,  many  companies  store  data  about  these  business  transactions. 
However,  the  data  entry  function  associated  with  the  exchange  of  business  documents 
is  costly  in  terms  of  time  and  data  entry  errors.  These  shortcomings,  coupled  with 
the  inherent  latency  of  the  exchange  of  paper  business  documents  lead  to  the  creation 
of  Electronic  Data  Interchange. 

Although  most  individuals  agree  on  the  basic  concepts  behind  EDI,  there  have 
been  many  definitions  put  forth  to  describe  it.  See,  for  example  [Dat93],  [Coa88], 
[Emm90],  [GT94],  [HH93]  and  [AEHJ95].  The  essential  features  of  EDI  are: 

^For  an  in-depth  treatment  of  EDI  concepts  with  examples,  please  refer  to  [AEHJ95]. 
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•  Business  transactions  have  some  commonality  across  businesses  and  across  in¬ 
dustries. 

•  Business  transactions  can  be  standardized.  For  example,  the  purpose  and  con¬ 
tents  of  a  purchase  order  can  be  agreed  upon  by  most  businesses. 

•  Processing  of  standardized  transactions  can  be  automated. 

2.1  EDI  Benefits  to  Business 

The  use  of  EDI  can  benefit  a  business  in  many  ways.  All  of  the  following  benefits  of 
using  EDI  lead  to  cost  savings  either  directly  or  indirectly  through  fewer  man-hour 
requirements  (summarized  from  [SS92],  [Dat93]  and  [HH93]). 

•  Using  EDI  shortens  the  processing  time  for  incoming  and  outgoing  business 
documents. 

•  Using  EDI  reduces  requirements  for  paper,  printing  supplies  and  postage. 

•  Using  EDI  reduces  requirements  for  the  number  of  data  processing  and  clerical 
staff  such  as  order  entry  personnel. 

•  Using  EDI  increases  the  quality  of  the  data  in  information  systems.  Data  entry 
errors  are  eliminated. 

•  Using  EDI  can  allow  for  lower  inventory  levels  to  be  maintained  since  ordering 
cycles  are  much  shorter. 

The  quantifiable  benefits  listed  above  may  lead  to  the  following  benefits  for  an 
organization  that  adopts  EDI. 

•  Better  customer  response  [SS92].  Customers  can  receive  better  quality  infor¬ 
mation  such  as  order  or  delivery  status. 

•  Uniform  communications  with  all  trading  partners  [Dat93].  Fewer  but  more 
robust  avenues  of  communication  may  simplify  communications.  For  example, 
the  U.S.  Department  of  Defense  (DoD)  has  made  steps  to  move  to  completely 
automated  bidding  and  contact  negotiation  systems  using  EDI  [HH93]. 

•  Increased  business  opportunities.  When  dealing  with  government  contracts.  Re¬ 
quests  for  Quotations  (RFQs)  are  frequently  distributed  to  potential  suppliers. 
Receiving  RFQs  electronically  via  EDI  can  allow  a  supplier  to  evaluate  more 
RFQs  and  to  generate  bids  in  response  [HH93]. 
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2.2  EDI  Standards 

In  1979  the  American  National  Standards  Institute  (ANSI)  began  developing  the  ASC 
X12  standards  for  EDI.  At  the  same  time,  with  the  emergence  of  many  multi-national 
companies  and  with  the  growing  global  economy,  there  was  a  pressing  need  for  in¬ 
ternational  standards.  In  1985  the  United  Nations  began  developing  the  EDIFACT 
standards  for  international  trade.  Both  sets  of  standards  describe  the  actual  format  of 
EDI  transactions  that,  if  adhered  to,  can  allow  trading  partners  to  exchange  business 
documents. 

Each  EDI  standard  (X12  and  EDIFACT)  are  comprised  of  a  series  of  transaction 
sets  that  are  used  for  specific  business  transactions.  The  following  are  examples  from 
the  ANSI  X12  standard: 


Transaction  Set 

Name  and  Use 

810 

Invoice 

820 

Payment  Order /Remittance  Advice 

840 

Request  for  Quotation 

843 

Response  to  Request  for  Quotation 

850 

Purchase  Order 

855 

Purchase  Order  Acknowledgment 

856 

Ship  Notice/ Manifest 

Over  time,  some  transaction  sets  are  improved  and  expanded  upon.  When  im¬ 
provements  are  made,  a  new  transaction  set  version  is  released.  For  example,  the 
ANSI  X12  transaction  set  850  -  Purchase  Order  has  been  updated  from  versions 
3010,  3020,  3030  and  now  is  currently  at  version  3040. 

2.3  EDI  Basic  Components 

EDI  requires  many  basic  components  that  work  together  to  extract,  package  and 
transmit  EDI  messages.  In  some  systems,  the  functionality  of  these  components  is 
combined  in  one  subsystem.  This  section  is  intended  to  give  an  overview  of  the  basic 
software  components  required  to  perform  EDI  transactions.  Many  businesses  will 
already  have  some  of  the  software  components,  such  as  a  database,  already  in  place. 
Other  software  components  must  be  purchased  from  commercial  sources  or  written 
by  the  organization’s  MIS  or  computer  programming  staff. 

Figure  1  gives  a  general  outline  of  the  flow  of  data  through  an  EDI  system  between 
two  trading  partners.  In  the  figure,  both  trading  partners  have  databases  that  are  used 
to  store  information  about  business  transactions.  These  databases  will  generally  not 
resemble  each  other.  By  using  the  appropriate  Extract  utility,  data  for  the  business 
transaction  can  be  extracted  to  an  ASCII  file  (a  procedure  known  as  Mapping)  which 
is  then  converted  to  an  EDI  Transaction  using  the  EDI  translation  software.  The 
final  step  from  the  originating  side  is  to  upload  the  EDI  transaction  to  a  Value  Added 
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Figure  1:  Flow  of  Data  showing  EDI  Components 

Network  (VAN)  or  directly  to  the  trading  partner.  The  procedure  is  reversed  on  the 
receiving  end. 

3  EDI  Translation  Software  Features 

This  section  will  describe  the  basic  features  most,  if  not  all,  reasonable  EDI  translation 
software  possess  and  some  additional  features  that  are  desirable  in  EDI  translation 
software.  Most  of  these  features  can  be  determined  by  reading  the  product  literature 
or  by  contacting  a  sales  representative  from  the  software  vendor. 

Each  EDI  translation  software  package  may  possess  these  features  to  varying  de¬ 
grees.  For  example  a  particular  package  may  only  support  a  few  of  the  ANSI  X12 
transaction  sets.  The  degree  to  which  an  EDI  translation  software  package  supports 
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these  features  is  addressed  in  the  technical  and  nontechnical  criteria  for  evaluating 
EDI  translators  in  section  4  starting  on  page  10. 

Often,  when  companies  first  begin  investigating  EDI,  a  simple  question  is  asked: 
“Which  EDI  software  should  we  buy  ?”  To  which  the  typical  answer  is:  “Buy  the 
software  that  meets  your  needs”.  To  determine  exactly  what  are  the  “needs”  of  an 
organization,  each  feature  outlined  below  includes  some  indication  of  why  the  feature 
is  important  and  how  this  can  aid  in  meeting  the  needs  of  the  organization. 

3.1  Basic  Features 

A  basic  feature  is  one  that  is  necessary  to  provide  a  rudimentary  level  of  EDI  use. 

•  Support  for  ANSI  X12  and/or  EDIFACT  standards 

EDI  translation  software  must  understand  either  one  or  both  of  these  standards 
in  order  to  exchange  transactions.  For  businesses  new  to  EDI,  the  EDI  standard 
in  use  by  the  potential  trading  partners  will  be  an  important  factor.  Typically, 
within  the  U.S.,  the  ANSI  X12  standard  is  used  whereas  the  EDIFACT  standard 
is  used  more  heavily  in  other  countries. 

Some  EDI  translator  software  vendors  charge  a  fee  for  each  transaction  set  to 
be  used.  For  example,  if  only  Purchase  Orders  and  Invoices  (transaction  sets 
850  and  810)  will  be  exchanged  via  EDI,  then  only  those  transaction  sets  would 
be  purchased. 

•  Updatable  Transaction  Sets 

As  new  versions  of  EDI  standards  are  released,  it  is  important  that  the  trans¬ 
lation  software  be  easily  upgradable  to  accommodate  them.  Translators  that 
implement  EDI  standards  which  can  not  be  upgraded  or  are  prohibitively  ex¬ 
pensive  to  upgrade  represent  a  less  attractive  solution. 

•  Reporting 

In  automated  EDI  systems,  orders,  invoices  and  other  business  transactions  can 
be  processed  automatically  without  human  intervention.  Some  mechanisms  are 
required  to  alert  personnel  when  any  errors  occur  in  the  format  of  an  EDI  trans¬ 
action  or  during  the  transmission  of  the  EDI  transaction.  Reporting  capabilities 
enable  the  EDI  translator  to  print  exception  reports  when  problems  occur  and 
summary  reports  of  daily,  weekly  or  monthly  EDI  activity. 

Several  EDI  translators  offer  customized  reporting  capabilities  that  allow  the 
user  to  create  reports  that  are  tailored  to  the  needs  of  the  organization. 

•  Computer  Hardware  and  Operating  system  support 

EDI  translators  run  on  a  wide  variety  of  computer  hardware  and  operating 
system  platforms.  A  heavy  volume  (over  200  transactions  per  day)  of  EDI 
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transactions  requires  more  powerful  computing  support  such  as  minicomputers, 
workstations  or  mainframes.  For  a  lower  volume  of  transactions,  either  stand 
alone  personal  computers  (PC)  or  a  Local  Area  Network  (LAN)  of  PCs  may 
suffice. 

EDI  translator  software  may  run  on  more  than  one  platform  while  maintaining 
compatibility.  Such  software  offers  an  upgrade  path  that  can  start  small  to 
meet  immediate  needs  but  can  also  scale  up  to  meet  potentially  heavy  volumes 
of  EDI  transactions. 

•  Security 

Many  EDI  transactions  deal  with  potentially  sensitive  data  such  as  Purchase 
Orders,  Invoices  and  Quotations.  Most  EDI  translator  packages  have  some 
security  mechanisms  in  place  to  prevent  unauthorized  access  to  data  and  to 
information  about  trading  partners. 

If  the  transactions  exchanged  with  trading  partners  are  sensitive,  then  security 
issues  at  all  levels  (not  just  at  the  EDI  translator)  should  be  addressed. 

•  Documentation 

All  EDI  software  should  be  provided  with  complete  and  clear  documentation 
that  can  inform  a  user  as  to  how  to  install  and  customize  the  EDI  translation 
software  to  suit  the  organization.  Good  quality  documentation  is  of  great  im¬ 
portance  when  integrating  EDI  translation  software  with  other  components  of 
an  EDI  system  such  as  databases  and  communications  softwaxe. 

Installation  guides  give  step  by  step  instructions  for  installing  the  basic  trans¬ 
lation  software.  Tutorials  teach  the  new  user  how  to  work  with  the  software 
to  customize  it  for  specific  trading  partners.  Reference  guides  contain  complete 
listings  and  definitions  of  all  commands  and  features  of  the  software. 

•  Technical  Support 

Documentation  can  only  go  so  far  when  troubleshooting  EDI  systems.  Often 
it  is  necessary  to  contact  the  software  vendor  for  advice  on  configuring  the 
software  and  to  report  bugs  or  other  problems. 

The  responsiveness  and  availability  of  technical  support  plays  a  large  role  in 
the  relationship  between  a  business  and  the  software  vendor.  Some  software 
vendors  charge  an  additional  fee  for  technical  support  while  others  may  only 
allow  free  technical  support  for  a  limited  time  period.  Note  also,  the  time  of  day 
when  technical  support  is  available  especially  if  the  software  vendor  is  located 
several  time  zones  away. 
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3.2  Additional  Features 


•  Built  in  database 

Many  EDI  translators  come  with  a  small  built  in  database  that  can  be  used  to 
enter  data  to  be  converted  into  EDI  transactions.  For  small  businesses  that  do 
not  have  an  existing  database,  this  can  be  an  attractive  alternative. 

Note,  however,  that  such  databases  are  typically  not  very  flexible  and  may  only 
contain  rudimentary  data  entry  screens  to  facilitate  entering  new  data  for  EDI 
transactions. 

•  Data  Mapping 

EDI  translators  require  some  form  of  input  file  that  is  then  converted  into  an 
EDI  transaction.  If  the  original  data  resides  in  a  corporate  database.  Mapping 
software  must  be  used  to  map  data  elements  in  the  database  to  the  appropriate 
EDI  transaction  components. 

Many  EDI  translators  have  mapping  capability  built  into  them  while  other 
software  vendors  provide  mapping  software  separately.  Some  stand  alone  PC 
implementations  also  include  a  built  in  database  and  mapping  software  to  form 
a  self-contained  system. 

The  need  for  mapping  software  depends  on  the  means  of  storage  for  the  original 
business  data. 

•  Communications  Capabilities 

EDI  transactions  are  typically  sent  either  directly  from  one  trading  partner  to 
another  or  via  a  Value  Added  Network  (VAN)  (See  Figure  1).  Communications 
software  is  responsible  for  sending  and  receiving  EDI  transactions  from  a  trading 
partner  or  VAN. 

As  with  mapping  software,  communications  capabilities  are  often  built  in  to 
the  EDI  translator  software.  This  arrangement  enables  one  software  package  to 
translate  and  then  send  off  an  EDI  transaction. 

•  Scheduling 

A  scheduler  is  a  piece  of  software  that  can  trigger  the  execution  of  a  task  at 
specified  times.  EDI  translation  software  may  incorporate  a  scheduler  to  per¬ 
form  some  translation  routines  at  a  specific  time  each  day.  For  example,  one 
might  set  the  scheduler  to  automatically  download  any  new  EDI  transactions, 
translate  them  into  flat  files  and  then  insert  them  into  the  company  database. 
This  series  of  events  might  be  scheduled  to  run  at  lOiOOam  and  2:00pm  on  each 
business  day. 

•  Training  and  Consulting  services 
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Many  EDI  software  vendors  offer  on-site  training  and  consulting  services  to 
help  businesses  new  to  EDI  get  up  to  speed  on  the  software  and  hardware. 
Such  services  normally  come  at  an  additional  price  and  may  vary  considerably 
between  software  vendors. 


4  Evaluation  Criteria 

In  section  3,  some  features  of  EDI  translation  software  were  introduced.  These  fea¬ 
tures  can  be  used  as  a  basis  when  comparing  software  from  different  vendors.  Along 
the  same  lines,  we  may  view  the  features  of  an  EDI  translator  as  the  criteria  for 
evaluation. 

The  evaluation  criteria  can  be  divided  into  two  groups:  Technical  criteria  that 
relate  to  the  technical  specifications  of  the  software  and  Nontechnical  criteria  that 
relate  to  the  software  vendors  themselves.  The  following  sections  will  introduce  the 
technical  and  nontechnical  criteria.  A  third  section  will  then  discuss  a  method  for 
cissigning  weights  to  all  of  the  criteria  in  preparation  for  evaluation. 

4.1  Technical  Criteria 

Technical  criteria  relates  to  the  specifications  of  the  EDI  translation  software.  Suc¬ 
cessful  EDI  implementations  depend  on  the  degree  to  which  the  technical  criteria  for 
the  EDI  translation  software  are  met.  For  example,  if  an  EDI  translator  only  supports 
the  ANSI  X12  standard  transactions,  then  the  software  would  not  be  appropriate  for 
projects  involving  international  trade. 

•  Standards  Support  and  Compliance 

EDI  translation  software  may  support  one  or  more  EDI  transaction  standards 
including  ANSI  X12,  EDIFACT  or  other  proprietary  standards.  Standards  com¬ 
pliance  deals  with  the  how  closely  the  software  implementation  follows  a  given 
standard.  When  new  versions  of  standards  are  released,  it  is  also  important  to 
know  what  the  software  vendor’s  policy  is  towards  upgrading  the  software  to 
meet  the  new  standards. 

The  important  issues  to  consider  are  whether  or  not  the  software  supports  the 
standards  required  by  the  trading  partners,  the  quality  of  the  implementation  of 
those  standards  and  the  ability  to  update  the  software  as  standards  are  revised. 

The  cost  of  providing  support  for  various  transaction  sets  is  addressed  in  the 
Nontechnical  Criteria  section  starting  on  page  14. 

•  Processing  Architecture 

EDI  translation  software  can  be  used  as  a  stand-alone  application  or  it  can  be 
used  in  conjunction  with  existing  information  systems.  The  latter  case  is  known 
cLS  an  integrated  EDI  system. 
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Stand-alone  translators  will  typically  have  a  limited  built  in  database  as  de¬ 
scribed  in  section  3.  This  facilitates  small  scale  EDI  transaction  flow  of  perhaps 
a  few  transactions  per  day.  This  solution  is  suitable  for  companies  with  a 
low  volume  of  business  transactions  and  works  especially  well  when  no  existing 
database  systems  are  in  use. 

Integrated  EDI  systems  require  more  work  to  install  and  attach  to  existing 
information  systems.  The  payoff  for  this  work  is  completely  automated  EDI 
capabilities  that  can  process  a  high  volume  of  EDI  transactions  without  human 
intervention. 

The  main  issue  for  processing  architecture  is  matching  the  type  of  EDI  system 
with  the  transaction  volume  and  existing  information  systems  of  the  company. 
EDI  translators  that  can  operate  in  both  stand-alone  and  integrated  modes  are 
the  best  choices. 

•  Hardware  and  Operating  System  Support 

The  EDI  translation  software  should  run  on  the  computer  hardware  platform 
and  in  conjunction  with  the  operating  system  employed  by  the  organization. 
If  existing  computers  are  to  be  used,  the  EDI  software  vendor  should  be  able 
to  supply  a  fully  supported  version  that  can  run  reliably.  If  the  goal  is  to 
eventually  upgrade  to  a  new  computer  platform  (e.g.  from  a  personal  computer 
to  a  UNIX  workstation),  the  EDI  translation  software  should  be  available  for 
both  platforms. 

As  with  processing  architecture,  the  volume  of  business  transactions  conducted 
with  EDI  will  typically  determine  the  type  of  computer  hardware  required. 

The  main  issues  for  computer  hardware  and  operating  systems  support  are  the 
availability  of  software  on  the  platform  of  choice  and  the  ability  to  scale  up  to 
more  powerful  systems  without  losing  the  initial  investment. 

•  Communications 

This  criteria  refers  to  the  built  in  or  additional  support  the  EDI  translator  has 
for  transmitting  and  receiving  EDI  transactions  from  a  Value  Added  Network 
(VAN)  or  directly  from  a  trading  partner  (See  Figure  1).  Some  EDI  transla¬ 
tors  have  communications  support  built  in  to  the  basic  product  leaving  only 
hardware  (such  as  a  modem)  to  be  added. 

Since  there  are  many  different  VAN  services  available,  as  well  as  the  option  to 
connect  directly  with  a  trading  partner,  the  ability  to  customize  the  communi¬ 
cations  software  and  support  for  a  wide  range  of  telecommunications  hardware 
are  the  main  issues. 

•  Security 
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To  protect  against  unauthorized  use  of  the  EDI  translator,  security  mechanisms 
should  be  available.  Many  systems  incorporate  simple  username  and  password 
protection  for  the  entire  software  package.  Others  allow  protection  at  a  finer 
level  by  enabling  or  disabling  system  functions  depending  on  the  current  user. 
The  latter  methods  are  more  difficult  to  set  up  initially  but  offer  the  finer  control 
over  accessing  the  translation  software. 

The  main  issues  for  security  are  the  availability  and  ease  of  which  mechanisms 
to  prevent  unauthorized  access  can  be  implemented. 

•  Documentation 

Clear,  concise  and  complete  documentation  is  an  invaluable  resource  when  in¬ 
stalling  and  learning  to  use  EDI  translation  software.  Separate  installation 
guides,  reference  guides  and  tutorials  offer  the  widest  range  of  help  for  new 
users. 

Installation  guides  should  offer  quick  steps  for  getting  up  and  running  quickly 
while  including  detailed  instructions  for  customizing  the  software  and  integrat¬ 
ing  it  with  additional  programs  such  as  communications  and  mapping  software. 

Reference  guides  should  contain  complete  explanations  of  all  of  the  software’s 
functions  and  would  ideally  include  references  to  the  relevant  EDI  standards 
documents. 

Tutorials  can  give  the  novice  user  documented  examples  for  configuring  and 
using  the  translation  software.  These  examples  can  then  be  extended  or  used 
as  a  basis  for  setting  up  the  translator  to  work  with  “real”  trading  partners. 

•  User  Interface 

The  user  interface  refers  to  the  parts  of  the  EDI  translation  software  the  end- 
user  works  with.  Some  common  user  interfaces  include  a  command  line,  menus 
and  graphical  user  interface  or  GUI. 

A  command  line  interface  requires  the  user  to  type  in  commands  in  order  to 
make  the  software  perform  various  functions.  For  example,  to  obtain  help  on 
performing  a  “Status”  function,  a  user  might  type: 

HELP  STATUS 

A  menu  driven  interface  allows  the  user  to  select  commands  from  a  list.  Ob¬ 
taining  help  on  the  above  function  would  be  as  easy  as  selecting  the  HELP  menu 
item. 

A  GUI  allows  the  user  to  perform  functions  by  manipulating  objects  on  screen 
with  a  pointing  device  such  as  mouse.  GUIs  are  fast  becoming  the  standard 
user  interface  for  software  in  all  industries.  For  example,  to  obtain  help  on  a 
function,  the  user  may  point  to  a  HELP  button  on  the  screen. 
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Each  style  of  interface  can  be  nicely  or  poorly  implemented.  It  is  possible  that 
a  bad  GUI  is  more  difficult  to  use  than  a  well  designed  menu  system. 

Some  user  interfaces  are  customizable  to  suit  the  needs  of  individuals.  For 
example,  additional  menu  items  might  be  added  to  perform  some  functions 
defined  by  the  user. 

The  main  issues  for  user  interface  are  whether  or  not  the  particular  user  interface 
makes  the  software  easy  to  use  and  if  it  is  customizable. 

Scheduler 

A  scheduler  can  help  automate  various  EDI  related  tasks  by  automatically  run¬ 
ning  the  communications  software,  translator  and  insert/extract  utilities  at  pre¬ 
set  times  during  the  day. 

Some  schedulers  allow  any  task  to  be  scheduled  while  others  can  only  schedule 
one  or  two  tasks.  The  flexibility  in  setting  the  timing  is  also  important.  For 
example,  a  company  may  wish  to  download  and  new  purchase  orders  from  a 
VAN  at  10:00am  on  Monday  through  Friday  but  not  on  the  weekends. 

The  main  issues  for  schedulers  are  the  ability  to  automate  both  EDI  tasks  and 
user  defined  tasks  and  the  flexibility  for  setting  execution  times. 

Reporting 

Reporting  functions  are  used  to  produce  exception  reports  when  there  are  errors 
in  transmission  or  errors  in  the  translation  process  and  to  produce  usage  reports 
that  indicate  which  transactions  have  been  processed. 

Error  or  exception  reports  are  a  basic  requirement  for  automated  EDI  systems. 
Without  such  reports,  the  business  has  no  idea  which  transactions  are  being 
processed  and  which  are  not.  Usage  reports  may  also  be  required  for  reconcilia¬ 
tion  with  accounting  records  should  a  discrepancy  occur.  Some  EDI  translator 
packages  may  also  offer  customized  reporting  features. 

The  important  issues  to  consider  are  whether  or  not  the  EDI  translation  software 
supports  the  types  of  reports  the  business  requires  and  if  the  reports  can  be 
customized. 

Error  Handling 

Aside  from  printing  an  exception  report,  the  handling  of  translation  errors  is  a 
very  important  part  of  EDI  translation  software.  Errors  in  translation  may  be 
attributed  to  data  transmission  errors  that  may  garble  parts  of  the  transaction. 
Errors  may  also  be  attributed  to  non-conformance  to  EDI  standards  at  the 
source  of  the  transaction.  If  one  trading  partner  is  using  software  that  incor¬ 
rectly  translates  EDI  transactions  (due  to  a  software  bug  or  non-conformance 
to  EDI  standards),  all  other  trading  partners  will  have  problems  reading  the 
transactions. 
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Some  errors  are  correctable  at  the  receiving  end  and  can  allow  a  transaction  to 
pass  through  and  be  accepted.  For  example,  a  transaction  may  not  conform  to 
the  latest  version  of  an  EDI  standard.  The  receiving  translator  might  recognize 
this  and  perform  the  translation  using  the  older  version  of  the  standard.  If 
errors  in  a  transaction  can’t  be  corrected,  both  trading  partners  must  be  alerted 
either  via  additional  EDI  messages  (in  this  case  a  negative  confirmation)  or  via 
exception  reporting. 

Error  handling  issues  include  the  ability  to  check  for  conformance  to  EDI  stan¬ 
dards,  the  means  for  correcting  errors  or  the  means  by  which  trading  partners 
are  alerted  to  any  problems. 

4.2  Nontechnical  Criteria 

Nontechnical  criteria  relates  to  the  specific  attributes  of  the  software  vendor  that 
supplies  the  software.  These  include  the  viability  of  the  vendor  in  the  EDI  transla¬ 
tion  software  market,  the  cost  for  software  and  accessories  and  other  factors  such  as 
technical  support  and  consulting  services. 

•  Software  Costs 

The  cost  of  EDI  translation  software  can  vary  widely  depending  on  the  features 
of  the  software  and  the  pricing  policies  of  the  software  vendor.  As  a  general 
framework  for  costs,  the  following  cost  breakdown  is  suggested: 

—  Translation  Engine  -  The  translation  engine  is  the  software  that  performs 
the  actual  translation.  This  core  component  is  required  for  all  EDI  trans¬ 
lation  software  systems  and  is  often  priced  separately. 

—  EDI  Transaction  Sets  -  Each  transaction  set  (e.g.  850  -  Purchase  Order) 
may  be  an  additional  cost.  Also,  new  versions  of  transaction  sets  (e.g. 
3030,  3040)  may  be  an  additional  cost. 

Some  software  vendors  bundle  all  of  the  ANSI  transaction  sets  or  all  of 
the  EDIFACT  transaction  sets  as  part  of  the  Translation  Engine  for  one 
price.  For  companies  that  require  many  different  transaction  sets,  this  is 
an  attractive  alternative. 

—  Communications  -  Some  EDI  translation  packages  have  built  in  communi¬ 
cations  programs  that  allow  EDI  transactions  to  be  uploaded  and  down¬ 
loaded  directly  into  the  translator.  Most  offer  communications  as  a  soft¬ 
ware  program  that  must  be  purchased  separately. 

—  Mapping  -  EDI  translation  software  that  offers  an  integrated  processing  ar¬ 
chitecture  will  often  include  a  mapping  component  to  aid  in  integrating  the 
translation  software  with  existing  information  systems.  If  this  capability 
is  not  built  in  to  the  translation  engine,  then  it  may  not  be  available  or  it 
may  be  available  at  an  additional  cost. 
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-  Scheduler  -  Most  EDI  translators  include  a  scheduling  function  to  run  the 
translation  and  communications  tasks  at  particular  times.  If  these  features 
are  not  included,  they  can  be  purchased  from  other  sources. 

-  Maintenance  -  Most  EDI  translation  software  vendors  offer  a  yearly  mainte¬ 
nance  plan  where  any  feature  enhancements  that  are  made  on  the  software 
product  (upgrades)  can  be  obtained.  The  maintenance  charge  is  typically 
a  small  fee  that  is  much  cheaper  than  outright  purchasing  a  new  version. 
Upgrades  that  fix  bugs  in  the  vendor’s  software  should  never  carry  an 
additional  charge. 

•  Technical  Support 

Technical  support  is  offered  by  the  EDI  translation  software  vendor  to  aid  in 
installing,  configuring  and  troubleshooting  the  software.  Fees  for  this  service 
range  from  free  to  support  plans  that  charge  a  certain  percentage  of  the  total 
software  cost  each  year  technical  support  is  requested. 

The  quality  of  technical  support  does  not  lend  itself  easily  to  quantitative  mea¬ 
sure,  however,  the  following  factors  may  be  considered: 

—  The  hours  of  operation  for  technical  support.  This  is  especially  important 
if  the  vendor  is  several  time  zones  away. 

-  The  familiarity  of  the  technical  support  staff  with  a  wide  variety  of  EDI 
installations  and  with  their  company’s  products. 

-  Any  extra  charges  that  are  associated  with  technical  support.  These  could 
include  the  cost  of  a  toll  call  or  a  per  minute  or  per  incident  charge. 

As  with  vendors  of  word  processing,  spreadsheet  and  other  application  software, 
the  trend  seems  to  be  to  offer  free  technical  support  for  a  limited  time  (i.e. 
90  days  after  purchase)  while  the  software  is  setup  and  configured.  The  vast 
majority  of  problems  requiring  troubleshooting  occur  during  this  time. 

•  Vendor  Attributes 

As  with  any  other  significant  purchase  (e.g.  a  stereo,  refrigerator,  automobile, 
etc.)  where  a  long  term  commitment  to  the  product  is  required,  concern  for  the 
position  of  the  vendor  in  the  respective  market  and  for  the  overall  health  of  the 
vendor  become  issues. 

The  following  are  criteria  that  reflect  these  concerns: 

-  Market  Share  -  Is  the  vendor  a  market  leader  in  number  of  sales  or  suc¬ 
cessful  installations  ? 

-  Years  in  Business  -  How  long  has  the  vendor  been  in  business  ? 
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—  Innovations  -  Does  the  vendor  have  the  capabilities  to  provide  innovative 
solutions  that  benefit  the  industry  ? 

—  Experience  -  How  much  experience  does  the  vendor  have  in  a  particular 
industry  (e.g.  food  manufacturing  or  ocean  shipping)  ? 

4.3  Weighting  the  Criteria 

Each  of  the  technical  and  nontechnical  criteria  described  in  sections  4.1  and  4.2,  vary 
in  importance  to  each  perspective  buyer  of  EDI  translation  software.  To  account  for 
this  variation,  each  of  the  criteria  can  be  assigned  a  weight  factor  representative  of 
its  importance. 

For  example,  if  the  goal  is  to  purchase  the  best  EDI  software  available  regardless 
of  cost,  then  technical  criteria  such  as  Standards  Support,  Reporting  and  User 
Interface  would  have  higher  weights  than  nontechnical  criteria  such  as  Software 
Costs.  Typically,  the  overall  goal  is  to  acquire  EDI  translation  software  that  meets 
the  business’  needs,  with  the  most  features,  for  the  least  cost. 

The  criteria  can  be  broken  down  to  form  a  hierarchy  as  follows.  Within  technical 
criteria,  each  of  the  factors  (e.g.  Standards  Support,  Reporting,  User  Interface,  etc.) 
are  given  weights  that  sum  to  1.00.  Within  nontechnical  criteria,  each  of  the  factors 
(e.g.  Software  Costs,  Technical  Support,  etc.)  are  assigned  weights  that  also  total  to 
1.00. 

Continuing  further,  within  the  nontechnical  criteria  of  Software  Costs,  each  of 
the  sub-criteria  (e.g.  Translation  Engine,  Transaction  Sets,  Communications,  etc.) 
are  weighted  such  the  total  weight  within  Software  Costs  equals  1.00.  All  of  the 
criteria  and  sub-criteria  are  broken  down  in  a  similar  fashion. 

Note  that  some  criteria  may  not  applicable  or  relevant  to  a  given  business.  In 
this  case,  the  criteria  can  be  given  a  weighting  of  0.00  or  simply  removed  from  the 
hierarchy.  For  example,  if  a  business  will  only  be  exchanging  business  transactions 
with  companies  in  Europe,  then  support  for  ANSI  X12  transactions  should  not  be  a 
consideration. 

By  assigning  weights  in  this  fashion,  it  becomes  easy  to  change  the  emphasis  at  any 
level  to  reflect  the  requirements  of  the  business  performing  the  evaluation.  A  sample 
criteria  hierarchy  for  technical  and  nontechnical  criteria  can  be  seen  in  Figures  2  and 
3  respectively. 

In  this  section,  the  criteria  for  the  evaluation  of  EDI  translation  software  were 
described  along  with  a  hierarchical  structure  for  weighting  the  criteria  to  emphasize 
the  importance  of  some  criteria  over  others.  Once  these  criteria  are  agreed  upon, 
the  tables  can  be  used  as  a  tool  to  evaluate  EDI  translation  software  packages  and 
vendors  and  to  compare  the  various  packages  available  on  the  market  today. 
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Hierarchy  Level 

Weight 

Standards  Support  and  Compliance 

1 

0.2 

X12  and/or  EDIFACT 

2 

0.5 

Version  Support 

2 

0.5 

Processing  Architecture 

1 

0.05 

Hardware/OS  Support 

1 

0.1 

Communications 

1 

0.05 

Security 

1 

0.1 

Documentation 

1 

0.1 

User  Interface 

1 

0.1 

Scheduler 

1 

0,1 

Reporting 

1 

0.1 

Error  Handling 

1 

0.1 

Figure  2:  Technical  Criteria  Hierarchy  with  Weights 


Nontechnical  Criteria 

Hierarchy  Level 

Weight 

Software  Costs 

1 

0.5 

Translation  Engine 

2 

Transaction  Sets 

2 

HIEHI 

Communications 

2 

HQSH 

Mapping 

2 

0.1 

Scheduler 

2 

IHSHi 

Maintenance 

2 

Technical  Support 

1 

0.3 

Hours  of  Operation 

2 

0.2 

Quality  of  Staff 

2 

0.5 

Extra  Charges 

2 

0.3 

Vendor  Attributes 

1 

0.2 

Market  Share 

2  ^ 

0.2 

Years  in  Business 

2 

0.4 

Innovations 

2 

0.2 

Experience 

2 

0.2 

Figure  3:  Nontechnical  Criteria  Hierarchy  with  Weights 
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5  Evaluation  Procedure 


In  section  4,  a  tool  was  developed  to  aid  in  the  evaluation  of  EDI  translation  software. 
In  this  section,  a  step  by  step  procedure  is  given  as  a  guide  for  evaluating  several 
software  packages.  Such  evaluations  are  typically  done  as  one  of  the  first  stages  of  an 
EDI  implementation  project. 

In  [AEHJ95],  the  authors  provide  an  overview  for  the  four  major  steps  of  an  EDI 
implementation  project.  They  are: 

1.  The  Planning  Stage  -  Where  all  of  the  background  research  into  the  organiza¬ 
tional  and  technical  impact  of  EDI  is  conducted. 

2.  The  Acquisition  and  Development  Stage  -  Where  the  hardware  and  software 
components  are  chosen  based  on  requirements  taken  from  the  planning  stage 
and  hardware  and  software  supplier  evaluations. 

3.  The  Pilot  Stage  -  Where  EDI  transactions  are  carried  out  with  one  or  two 
trading  partners. 

4.  The  Full  Implementation  Stage  -  Where  more  trading  partners  are  added,  usu¬ 
ally  one  at  a  time. 

In  the  planning  stage,  technical  requirements  such  as  the  volume  of  EDI  trans¬ 
actions,  the  number  of  potential  trading  partners  and  the  hardware  and  operating 
system  platforms  to  be  used  are  gathered.  These  requirements  should  be  noted  in  the 
context  of  the  evaluation  tool  presented  in  section  4. 

Once  the  requirements  have  been  established,  the  search  for  EDI  translation  soft¬ 
ware  can  begin.  By  following  the  weightings  of  the  criteria,  many  products  can  be 
ruled  out  right  away.  For  example,  if  UNIX  operating  system  support  is  required,  all 
products  that  can  not  run  under  UNIX  would  be  eliminated. 

Those  EDI  translators  that  meet  the  most  important  criteria  form  a  comparison 
set  from  which  one  or  two  final  EDI  translators  will  be  chosen.  The  next  step  is  to 
obtain  demonstration  versions  or  trial  versions  of  the  software  so  that  a  more  in-depth 
examination  of  the  features  can  be  performed.  Most  EDI  translation  software  vendors 
are  happy  to  provide  a  demo  or  trial  version  for  this  purpose. 

Once  demo  versions  have  been  obtained,  scores  for  all  of  the  criteria  at  the  lowest 
level  of  the  hierarchy  can  be  obtained.  For  example,  for  the  nontechnical  criteria 
shown  in  Figure  3,  the  following  criteria  would  be  considered: 

•  Costs  for  the  Translation  Engine 

•  Costs  for  the  Transaction  Sets 

•  Costs  for  the  Communications  module 
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•  Costs  for  the  Mapping  software 

•  Costs  for  the  Scheduler  software 

•  Costs  for  the  Maintenance  agreement 

•  Technical  support  Hours  of  Operation 

•  The  Quality  of  Staff  for  Technical  support 

•  Extra  charges  for  Technical  Support 

•  Vendor  Market  Share 

•  Number  of  Years  in  Business 

•  Product  Innovations 

•  Experience  in  various  industries 

The  scores  for  each  EDI  translator  can  be  made  relative  to  one  another.  For 
example,  if  the  costs  for  four  EDI  translator  engines  are  as  follows: 

EDI  Translator  A  $9,000 
EDI  Translator  B  $4,000 
EDI  Translator  C  $3,000 
EDI  Translator  D  $1,000 

then  EDI  Translator  D  would  get  the  highest  score.  Scores  can  generally  be  done 
on  a  range  from  1  to  10  so  EDI  Translator  D  would  receive  10  points,  C  would  receive 
9  points,  B  would  receive  8  points  and  A  would  receive  7  or  fewer  points  since  the 
cost  is  much  higher. 

Once  all  of  the  scores  for  the  lowest  level  of  the  hierarchy  are  obtained,  each 
category  can  be  calculated  by  multiplying  the  scores  by  the  weight  factor  and  then 
Slimming  the  product.  Figure  4  shows  the  results  for  rolling  up  all  of  the  lower  level 
criteria  for  two  different  EDI  translators  (A  and  B).  The  scores  were  computed  as 
follows: 

•  B’s  translation  engine  costs  less  than  A’s. 

•  A  gives  away  all  of  the  transaction  sets  for  a  low  fee  while  B  charges  for  each 
additional  transaction  set. 

•  Communications  software  is  built  in  to  A’s  translation  engine  so  it  incurs  no 
extra  cost.  B’s  is  a  separate,  but  inexpensive  add  on. 

•  The  mapping  software  is  an  additional  charge  for  both  A  and  B  but  B’s  is  less 
expensive. 
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Weight 

Score  A 

Score  B 

1 

8 

6.1 

Translation  Engine 

2 

8 

9 

Transaction  Sets 

2 

0.2 

9 

5 

Communications 

2 

0.1 

10 

8 

Mapping 

2 

0.1 

5 

8 

Scheduler 

2 

5 

8 

Maintenance 

2 

iimgiii 

9 

4 

Technical  Support 

1 

0.3 

8.8 

5.8 

Hours  of  Operation 

2 

0.2 

8 

9 

Quality  of  Staff 

2 

0.5 

9 

5 

Extra  Charges 

2 

0.3 

9 

5 

Vendor  Attributes 

1 

IIIQQI 

5.8 

7.8 

Market  Share 

2 

HESIl 

7 

9 

Years  in  Business 

2 

0.4 

3 

9 

Innovations 

2 

0.2 

3 

Experience 

2 

0.2 

6 

9 

Overall  Nontechnical  Score 

7.8 

6.35 

Figure  4:  Nontechnical  Criteria  Hierarchy  with  Scores  for  Two  EDI  Translators 

•  The  scheduling  software  is  also  an  additional  charge  for  both  A  and  B  but  again, 
B’s  is  less  expensive. 

•  A  offers  a  complete  maintenance  package  for  a  small  additional  fee  whereas  B 
has  a  very  limited  agreement  that  is  very  costly. 

•  As  for  technical  support,  both  offer  similar  hours  of  operation  but  A’s  support 
staff  is  more  knowledgeable  about  their  products  and  technical  support  is  free 
for  the  first  year. 

•  In  the  Vendor  Attributes  criteria,  B  has  been  in  business  much  longer  than 
A  has  but  they  have  no  new  innovations.  A  is  a  younger  company  with  very 
innovative  products  but  suffers  from  lack  of  market  share  and  broad,  cross- 
industry  experience. 

Note  that  even  though  one  translator  dominates  in  one  or  two  categories,  because 
of  the  weights,  it  is  possible  that  the  overall  score  will  show  the  other  translator  as  the 
better  choice.  In  this  example,  A  has  superior  technical  support  but  lags  behind  in 
the  other  criteria.  Translator  B  would  be  the  overall  better  choice  when  considering 
just  the  nontechnical  criteria. 
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As  an  overview,  from  the  EDI  translation  software  evaluation  perspective,  the 
following  steps  would  be  followed: 

1.  Establish  a  set  of  criteria  for  EDI  translation  software. 

2.  Weight  the  criteria  in  order  of  importance  to  the  success  of  the  EDI  project. 

3.  Review  the  features  of  various  EDI  software  packages  eliminating  those  that 
do  not  meet  the  most  important  criteria  such  as  operating  system  support  and 
transaction  set  support. 

4.  From  the  remaining  set  of  EDI  translators,  obtain  demo  or  trial  versions  of  the 
software.  Install  each  and  fill  in  the  scores  for  each  criteria  at  the  lowest  level. 

5.  Based  on  the  weights,  calculate  the  overall  scores  for  technical  and  nontechnical 
criteria. 

6.  If  the  overall  scores  vary  considerably,  as  in  the  example  in  Figure  4,  then 
the  EDI  translation  software  with  the  highest  score  should  be  considered  for 
purchase  in  the  Acquisition  and  Development  Stage. 

When  scores  are  closer  together,  the  decision  is  less  clear.  In  this  case,  it  is 
possible  that  small  changes  in  the  weightings  can  affect  which  product  has  the 
highest  score.  In  such  a  case,  any  software  package  that  has  a  comparable  score 
can  be  considered  for  purchase.  It  is  also  possible  to  re-weight  the  criteria  plac¬ 
ing  more  emphasis  on  criteria  where  the  products  differ  and  place  less  emphasis 
on  those  criteria  with  similar  scores. 
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6  Conclusions 


In  this  paper,  a  brief  introduction  to  EDI  was  given  including  the  major  software 
components  required  to  implement  an  EDI  system.  Of  these  components,  the  EDI 
translator  is  perhaps  the  most  important  piece  because  it  embodies  and  upholds  the 
EDI  standards  that  are  crucial  for  the  interchange  of  electronic  business  transactions. 

There  are  many  EDI  translator  software  packages  on  the  market  today.  To  eval¬ 
uate  these  packages,  a  series  of  technical  and  nontechnical  criteria  were  developed 
and  a  formal  method  for  using  these  criteria  was  introduced.  This  evaluation  proce¬ 
dure  can  be  viewed  as  an  outline  for  organizing  and  highlighting  the  most  important 
criteria  for  EDI  translation  software.  The  CRAMTD  project  intends  to  carry  this 
work  further  by  performing  evaluations  based  on  these  techniques  on  a  number  of 
EDI  translators  to  be  used  in  the  manufacturing  facility. 
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7  Glossary 


ACH 

Automated  Cleaa-ing  House 

AUG 

Automotive  Industry  Action  Group 

ANSI 

American  National  Standards  Institute 

ASC 

Accredited  Standards  Committee 

ASCII 

American  Standard  Code  for  Information  Interchange 

BBS 

Bulletin  Board  Service 

CAD 

Computer  Aided  Design 

CAE 

Computer  Aided  Engineering 

CAM 

Computer  Aided  Manufacturing 

CIM 

Computer  Integrated  Manufacturing 

DISA 

Data  Interchange  Standards  Association 

DLA 

Defense  Logistics  Agency 

DoD 

Department  of  Defense 

DPSC 

Defense  Personnel  Support  Center 

EC 

Electronic  Commerce 

EDI 

Electronic  Data  Interchange 

EDU 

Electronic  Data  Interchcinge  Association 

EDIFACT 

Electronic  Data  Interchange  for  Administration,  Commerce  and  Transport 

EFTA 

European  Free  Trade  Association 

EFT 

Electronic  Fimds  Transfer 

E-Mail 

Electronic  Mail 

ERS 

Evaluated  Receipt  Settlement 

FAR 

Federal  Acquisition  Regulation 

FIPS 

Federal  Information  Processing  Standards 

FMS 

Financial  Management  Service 

FRB 

Feder2d  Reserve  Bank 

IETF 

Internet  Engineering  Task  Force 

IGES 

Initial  Graphics  Exchange  Specification 

IOC 

Initial  Operational  Capability 

lOS 

Inter- Organizational  Information  Systems 

ISO 

International  Standards  Organization 

JIT 

Just  In  Time 

Multipurpose  Internet  Mail  Extensions 

Message  Transfer  Agent 

Nil 

National  Information  Infrastructure 

NIST 

National  Institute  of  Standards  and  Technology 

NTE 

Note  segment  of  an  EDI  message 

OLDB 

On  Line  DataBase 

PC 

Personal  Computer 

PDE 

Product  Data  Exchange 

PDES 

Product  Data  Exchange  using  STEP 

PO 

Purchase  Order 

RDA 

Remote  Database  Access 

RFC 

Request  For  Comment 

RFP 

Request  For  Proposal 

RFQ 

Request  For  Quotation 

SBA 

Small  Business  Administration 

SF 

Standard  Form 

SGML 

Stand^ud  Generalized  Mark-up  Language 

SNA 

Systems  Network  Architecture 

STEP 

Standard  for  The  Exchange  of  Product  Model  Data 
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TDCC 

Xransportation.  Data  Coordinating  Committee 

TDED 

UNECE  Trade  Data  Elements  Directory 

TDID 

Trade  Data  Interchange  Directory 

TEDIS 

Trade  Electronic  Data  Interchcmge  Systems 

TPA 

Trading  Partner  Agreement 

TQM 

Total  Quality  Management 

TS 

Trainsaction  Set 

TSDS 

Transaction  Set  Development  System 

UN-EDIFACT 

International  EDI  standards  committee 

UN/ECE 

United  Nations  Economic  Commission  for  Europe 

VAN 

Value  Added  Network 

VAS 

Value  Added  Service 

X12 

ANSI  ASC  sub-committee  charged  with  defmmg  U.S.  EDI  standards. 
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